Perl 6 - the future is here, just unevenly distributed

IRC log for #gluster-dev, 2014-06-02

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:16 bala joined #gluster-dev
02:18 hagarth joined #gluster-dev
02:53 bala joined #gluster-dev
02:55 bharata-rao joined #gluster-dev
03:24 kshlm joined #gluster-dev
03:43 itisravi joined #gluster-dev
03:51 nishanth joined #gluster-dev
03:53 shubhendu joined #gluster-dev
04:04 hagarth1 joined #gluster-dev
04:12 deepakcs joined #gluster-dev
04:24 dlambrig joined #gluster-dev
04:24 kkeithley1 joined #gluster-dev
04:35 ppai joined #gluster-dev
04:40 kdhananjay joined #gluster-dev
04:54 spandit joined #gluster-dev
05:05 aravindavk joined #gluster-dev
05:12 hagarth joined #gluster-dev
05:18 ndarshan joined #gluster-dev
05:27 vpshastry joined #gluster-dev
05:32 raghu joined #gluster-dev
05:34 krishnan_p joined #gluster-dev
05:35 kanagaraj joined #gluster-dev
05:47 aravindavk joined #gluster-dev
05:48 hagarth joined #gluster-dev
05:52 aravindavk joined #gluster-dev
06:03 lalatenduM joined #gluster-dev
06:10 bala1 joined #gluster-dev
06:29 aravindavk joined #gluster-dev
06:39 hagarth joined #gluster-dev
06:49 krishnan_p joined #gluster-dev
06:51 nishanth joined #gluster-dev
06:57 spandit joined #gluster-dev
07:02 swebb joined #gluster-dev
07:17 nishanth joined #gluster-dev
07:26 xavih joined #gluster-dev
07:59 spandit joined #gluster-dev
08:52 spandit joined #gluster-dev
08:55 vpshastry joined #gluster-dev
09:16 edward1 joined #gluster-dev
09:17 aravindavk joined #gluster-dev
09:24 kshlm JustinClift, are archived logs from the rackspace slaves downloadable?
09:27 spandit joined #gluster-dev
09:47 aravindavk joined #gluster-dev
09:52 bharata-rao joined #gluster-dev
09:59 dachary joined #gluster-dev
09:59 dachary dlambrig: \o
10:00 * dachary looking at http://review.gluster.org/#/c/7782/
10:00 glusterbot Title: Gerrit Code Review (at review.gluster.org)
10:01 dachary dlambrig: the paper that is guiding my implementation of pyramid erasure code : http://anrg.usc.edu/~maheswaran/Xorbas.pdf
10:02 dachary and the idea I don't quite understand is "implied parity block"
10:31 dachary telnet review.gluster.org 29418
10:31 dachary blocks and never returns. Is it just me ?
10:32 hagarth dachary: telnet review.gluster.org 22 works ;-)
10:32 ndevos dachary: should you not use port 22?
10:32 dachary oh. I'm trying to figure out the proper .gitreview ;-)
10:33 * dachary trying port 22
10:33 spandit joined #gluster-dev
10:33 dachary better ;-)
10:34 ndevos dachary: I dont use a .gitreview, just call the remote 'gerrit' ;)
10:34 dachary ndevos: hagarth thanks !
10:34 dlambrig dachary: thanks!
10:34 dachary ndevos: now I realize that would have been a good move :-)
10:35 ndevos dachary: oh, if you do that, make sure to also have a 'origin', otherwise ./rfc.sh might not work
10:35 * dachary renames gluster into origin
10:37 vpshastry joined #gluster-dev
10:42 skoduri joined #gluster-dev
10:46 vpshastry joined #gluster-dev
10:48 lalatenduM joined #gluster-dev
10:54 rgustafs joined #gluster-dev
10:57 kshlm joined #gluster-dev
11:12 ira joined #gluster-dev
11:16 ppai joined #gluster-dev
11:16 dlambrig left #gluster-dev
11:38 spandit joined #gluster-dev
11:53 bala1 joined #gluster-dev
12:03 edward1 joined #gluster-dev
12:06 itisravi joined #gluster-dev
12:10 hchiramm__ joined #gluster-dev
12:10 spandit joined #gluster-dev
12:18 dachary dlambrig1: do you know how was glusterfs/xlators/cluster/ec/src/ec-gf.c generated ? ( as found in  http://review.gluster.org/#/c/7749/ )
12:18 glusterbot Title: Gerrit Code Review (at review.gluster.org)
12:23 bala1 joined #gluster-dev
12:25 ndevos dachary: you can ask xavih here too :)
12:25 dachary ah, ndevos thanks ! I did not know the nick :-0
12:26 ndevos :)
12:43 bala1 joined #gluster-dev
12:51 dachary dlambrig1: xavih is it the responsibility of the client to check if the erasure coded chunks are indeed present even if they are not accessed ? i.e. some kind of periodic health check
12:52 * dachary noob :-)
12:52 lalatenduM joined #gluster-dev
13:06 awheeler joined #gluster-dev
13:06 itisravi_ joined #gluster-dev
13:12 xavih dachary: in the current version health check is performed only on access
13:13 xavih dachary: a modification will be made to make use of changelog and be more proactive, similar to the current self-head daemon
13:21 dachary xavih: the self-heal daemon runs from time to time and tries to access objects, checking if they are healthy ?
13:23 xavih dachary: not really. It inspects if there are uncompleted operations on any brick and tries to heal them. You can also force a full self-heal, that looks at all files and verifies that they are healthy
13:24 dachary xavih: could you please tell me how was glusterfs/xlators/cluster/ec/src/ec-gf.c generated ? ( as found in  http://review.gluster.org/#/c/7749/ )
13:24 glusterbot Title: Gerrit Code Review (at review.gluster.org)
13:24 xavih dachary: AFAIK this is how replicate self-heal works. Erasure code xlator does not use this yet
13:25 dachary xavih: understood
13:26 xavih dachary: it could be seen as an "unroll" of the multiplication operation in the galois field
13:26 xavih dachary: the main point is how I interpret the incoming data
13:26 hchiramm__ joined #gluster-dev
13:27 dachary xavih: ok. Did you manually generate this file or did you use a script of some kind ?
13:27 dachary xavih: it is really nice to see how small and self contained you've implemented this.
13:27 xavih dachary: I take 8 blocks of 128 bits. These blocks are interpreted as 128 bytes, where the first bit of each byte corresponds to the first block of 128 bist, the second bit corresponds to the second block...
13:28 xavih dachary: yeah, it's quite fast :)
13:28 xavih dachary: I used a program, based on brute force with some heuristics
13:29 dachary xavih: could I read this program somewhere ?
13:29 xavih dachary: it can be optimized a bit by using register renaming, but since it's quite fast, I haven't done that yet
13:31 xavih dachary: well, the program is quite "dirty" and it's not published (and will have to search where it is...), but I can send it to you if you are interested
13:32 dachary xavih: my questions regarding the mathematics of erasure code are naive because it is well above my paygrade ;-) for the ceph implementation I relied fully on jerasure. I'm impressed by your level of understanding.
13:32 dachary I'm most interested by the program, yes. There is no such thing as a dirty program. Only code that works and code that does not ;-)
13:32 xavih dachary: well, the field of erasure code is very wide. I only know a little part of it...
13:33 xavih Ok, I'll try to find the most recent version and send it to you :)
13:33 dachary cool
13:33 dachary do you have an opinion on the strategy developped in https://bitbucket.org/jimplank/gf-complete ?
13:33 glusterbot Title: jimplank / gf-complete Bitbucket (at bitbucket.org)
13:36 xavih I haven't looked at it. One of the thinks I'll do when the current version is stable enough is to look at some libraries to see if one of them can be used to replace current implementation, including one that is being developed by intel
13:36 dachary https://01.org/storage-acceleration-library/downloads/2014/isa-l-open-source-release
13:36 glusterbot Title: ISA-L open source release | 01.org (at 01.org)
13:37 _Bryan_ joined #gluster-dev
13:37 * dachary pats glusterbot on the back
13:37 xavih yes, that one :)
13:37 dachary :-)
13:39 dachary xavih: dlambrig1: mentioned that you chose to not rely on a systematic code and I'm curious about your rationale
13:41 xavih dachary: we currently use a Vandermonde matrix, that is not systematic, but has the property that it's very easy to multiply a row by a vector because each column of the row is equal to the previous multiplied by a constant
13:41 xavih this is quite fast to implement
13:43 xavih I don't have a "decisive" reason to use non systematic matrices. It's simply that the matrix multiplication is fast enough and it provides an efficient implementation
13:44 xavih each row in a Vandermonde matrix has the following structure: 1 a a^2 a^3 a^4 ...
13:44 xavih I use the row number for 'a'
13:44 dachary ok
13:45 * ndevos <- (o_O)
13:46 dachary xavih: cute
13:46 xavih then multiplying this row by a vector is quite easy: (1 a a^2 a^3) * (w x y z) = w + a * (x + a * (y + a * z)))
13:47 xavih I simply multiply by the same value and add, multiply, add, ...
13:47 dachary xavih: what's the throughput of the function ? I mean how many mega bytes per second can it process ?
13:48 dachary for encoding / decoding
13:49 xavih dachary: for encoding it can generate about 2 bytes per cycle per core (on an intel Atom processor)
13:50 dachary oh, that's an interesting way to put it
13:50 xavih dachary: decoding is heavily conditioned by the inversion of the matrix, that could be time consuming
13:51 xavih dachary: with a somewhat big matrix (16 x 16) on an Atom processor it could do about 200 MB/s
13:51 xavih dachary: We plan to improve this by caching inverted matrices
13:52 dachary so for a 3Ghz core encoding will be as fast as 6Ghz for K=2, M=1 ?
13:52 skoduri joined #gluster-dev
13:52 dachary s/6Ghz/6MB/s
13:53 ndk joined #gluster-dev
13:56 xavih dachary: well, not exactly sorry. 2 bytes per cycle is the speed of multiplication. To get the K + M fragments you must do K * (K + M) multiplications
13:57 xavih in your case it should work at ~1GB/s
13:57 dachary oh, right
13:58 dachary K is the number of data chunks and M the number of coding chunks ? Or do you use another convention ?
13:59 rgustafs joined #gluster-dev
13:59 xavih I interpreted the M as the number of redundant bricks (the number of bricks that can fail without data loss) and K the number of fragments in which a block of data is split
14:00 xavih K=2 and M=1 means a total of 3 bricks, right ?
14:00 xavih and you cannot lose more than one
14:01 dachary yes, we're in agreement ;-)
14:02 xavih :)
14:02 * dachary wondering why mathematicians chose K+M instead of data+coding or D+C
14:03 dachary xavih: I would be most interested to know your opinion about http://web.eecs.utk.edu/~plank/plank/papers/FAST-2013-GF.pdf . It will hopefully inspire you to optimize the current code (if at all possible ;-)
14:07 xavih I think I read something very similar some time ago... not sure if it was this one though...
14:07 xavih I'll read it :)
14:08 hchiramm_ joined #gluster-dev
14:17 dachary to my knowledge that's the only paper ever published describing this approach
14:19 wushudoin joined #gluster-dev
14:28 jobewan joined #gluster-dev
15:12 dachary xavih: did you consider localy repairable codes as a mean to reduce the network bandwidth when recovering from the loss of a single chunk ?
15:25 xavih dachary: no. We have only worked with "normal" erasure codes
15:26 xavih dachary: I think you are looking at pyramid codes for ceph. It seems interesting, but I don't have any experience here
15:29 dachary I'm working on that but I'll end up doing just LRC because I don't quite see how it is different / better than pyramid code. Except the name is sexy ;-)
15:31 xavih dachary: I've just sent you the program to generate the xors sequences for Galois field multiplications
15:37 aravindavk joined #gluster-dev
15:38 * dachary reading http://research.microsoft.com/pubs/70415/tr-2007-25.pdf
15:38 dachary xavih: thanks !
15:41 dachary I'm definitely not going to implement pyramid code and stick to LRC because it's much simpler
15:42 dachary and the benefit is high
15:42 dachary a good tradeoff ;-)
15:46 hagarth joined #gluster-dev
16:17 hagarth joined #gluster-dev
16:25 shubhendu joined #gluster-dev
16:46 hagarth joined #gluster-dev
16:48 skoduri joined #gluster-dev
16:50 aravindavk joined #gluster-dev
17:03 vpshastry joined #gluster-dev
17:14 skoduri joined #gluster-dev
18:39 edward1 joined #gluster-dev
21:30 ndk joined #gluster-dev
22:54 avati joined #gluster-dev
23:00 a2 joined #gluster-dev

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary