Camelia, the Perl 6 bug

IRC log for #gluster-dev, 2013-09-03

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

All times shown according to UTC.

Time Nick Message
02:52 vshankar joined #gluster-dev
03:24 bharata-rao joined #gluster-dev
03:35 shubhendu joined #gluster-dev
03:38 awheeler joined #gluster-dev
03:52 itisravi joined #gluster-dev
04:04 kanagaraj joined #gluster-dev
04:05 ndarshan joined #gluster-dev
04:13 shubhendu joined #gluster-dev
04:16 kshlm joined #gluster-dev
04:24 ababu joined #gluster-dev
04:25 ppai joined #gluster-dev
04:27 ababu joined #gluster-dev
04:34 spandit joined #gluster-dev
04:53 aravindavk joined #gluster-dev
04:55 hagarth joined #gluster-dev
04:58 bala joined #gluster-dev
05:11 bulde joined #gluster-dev
05:21 lalatenduM joined #gluster-dev
05:23 lala_ joined #gluster-dev
05:24 raghu joined #gluster-dev
05:47 ajha joined #gluster-dev
05:52 vshankar joined #gluster-dev
06:32 aravindavk joined #gluster-dev
06:37 rgustafs joined #gluster-dev
07:21 mohankumar__ joined #gluster-dev
07:26 ndarshan joined #gluster-dev
08:16 shubhendu joined #gluster-dev
09:05 bulde joined #gluster-dev
09:14 bala joined #gluster-dev
09:20 bulde1 joined #gluster-dev
09:25 shubhendu joined #gluster-dev
09:29 kanagaraj joined #gluster-dev
10:04 shubhendu joined #gluster-dev
10:06 kanagaraj joined #gluster-dev
10:10 bulde joined #gluster-dev
10:15 ndarshan joined #gluster-dev
10:23 ababu joined #gluster-dev
10:28 aravindavk joined #gluster-dev
10:29 edward1 joined #gluster-dev
11:02 rfortier joined #gluster-dev
11:22 hagarth joined #gluster-dev
11:53 bulde joined #gluster-dev
12:01 kanagaraj joined #gluster-dev
12:41 jclift joined #gluster-dev
12:42 bulde joined #gluster-dev
12:59 hagarth joined #gluster-dev
13:02 kanagaraj joined #gluster-dev
13:07 lpabon joined #gluster-dev
13:18 bulde joined #gluster-dev
13:29 kkeithley lpabon: sorry I didn't see your question on Friday. I didn't see a review request on fedora-devel; did you send it?
13:29 lpabon yes, here is the link https://bugzilla.redhat.co​m/show_bug.cgi?id=1003089
13:29 glusterbot Bug 1003089: medium, medium, ---, nobody, NEW , Review Request: glusterfs-openstack-swift - Gluster for Swift
13:30 kkeithley don't you need to send that to the fedora-devel mailing list too?
13:31 kkeithley and cc: Matthias Runge? ;-)
13:31 lpabon it does not mention that in http://fedoraproject.org/w​iki/Package_Review_Process
13:31 lpabon but i can
13:33 kkeithley I think it speeds things up, in theory. (There are lots of review requests, review swap requests on the mailing list, that's what prompted me to ask, even though it may not be strictly required.)
13:34 lpabon ah ok
13:34 lpabon should I cc you also?
13:34 kkeithley sure
13:35 lpabon what is matthias ruge's email address?
13:35 kkeithley mrunge@redhat.com
13:36 lpabon cool thanks
13:56 jbrooks joined #gluster-dev
14:02 Technicool joined #gluster-dev
14:15 awheeler joined #gluster-dev
14:16 awheeler joined #gluster-dev
14:17 wushudoin joined #gluster-dev
14:33 _Bryan_ joined #gluster-dev
14:45 badone joined #gluster-dev
14:47 mohankumar__ joined #gluster-dev
14:51 awheeler joined #gluster-dev
14:52 mohankumar joined #gluster-dev
16:28 kanagaraj joined #gluster-dev
17:16 hagarth joined #gluster-dev
17:22 lpabon joined #gluster-dev
17:35 hagarth joined #gluster-dev
17:55 lalatenduM joined #gluster-dev
18:23 avati bfoster: ping
18:23 foster avati: pong
18:23 avati foster: hey.. couple of things
18:24 avati i plan to merge the qcow2 snapshot patches now.. do you want anything else addressed in those patches before merge?
18:24 foster ok. nope, that sounds great. I was planning to play more with them once merged
18:26 avati ok merged
18:26 avati another topic.. this was something i was just thinking about, nothing concrete yet
18:27 avati remember the fiemap based snapshotting writeup I had shared with you sometime back?
18:27 foster yep
18:27 avati the problem with that was, fiemap was not reliable
18:27 avati and what we needed from fiemap was whether the region was modified or not (not the actual block mappings themselves)
18:28 avati i was thinking, we could maintain a dirty bitmap in the xattr which represents which blocks have been modified in the delta file and avoid fiemap entirely
18:29 avati the bitmap would likely use a larger block size (given the ratio of ideal xattr size : typical file size)
18:30 avati *represent a larger block size
18:30 foster if we could do that, couldn't we use an "extent map" like format?
18:31 avati we "could.." essentially maintain extent map in the xattrs
18:31 avati that would be a tradeff between granularity vs complexity+space consumption
18:32 foster yeah, where "extent map" means "modify map" or whatever to avoid terminology confusion
18:32 avati right.. given that offsets are 64bit, i suspected the modify map can grow quite large
18:33 avati whereas a bitmap was fixed size and constant time operations.. but nothing inherantly against modify maps
18:34 foster well a bitmap would get large as well, wouldn't it?
18:35 avati bitmap would be fixed size for a given file size.. the worst case size of a modify map for a given file size can be very big if the modifications are too sparse
18:36 avati of course, the best case of a modify map can be significantly smaller than a bitmap too
18:36 foster right, but it depends on the file size
18:36 foster i guess it depends on the level of expected modification to determine if worthwhile
18:36 avati i think it depends on the "sparseness" of modifications
18:36 foster but I was wondering that if we had something like that, would it be useful for afr?
18:37 foster for "selective" self-heal, for example
18:37 foster similar to what md does on repair if a bitmap is enabled
18:37 avati i don't know what md does
18:38 foster basically it tracks what regions are dirty and have to be synced on repair
18:38 avati ok
18:38 foster I'd actually have to go back and look at it to remember the details
18:39 avati i think the answer there too depends on the sparsness of the changes
18:39 avati if the changes were too sparse, bitmap might be better for AFR.. if the changes were too close and collapsable ranges, then modify map
18:39 foster yep, but format aside, sounds like the mechanism would be useful eh?
18:39 avati *too many and too sparse
18:40 avati yes, ceratinly..
18:40 avati we could actually hide the details within.. whether we are using bitmap or modify map, and just present a single api
18:40 avati if the modifications become too many and too sparse, automatically swith cover to a bitmap below the covers
18:40 foster indeed, good point
18:45 avati anyways, this kind of a snapshotting might be a plan-B in case we come across unforeseen blockers by keeping qemu code in our code base
18:45 avati (or even option-B, in case we find the performance is inherantly too slow for some reason?)
18:46 foster yep, something to keep in mind for the longer term
18:49 foster hmm I suppose you could alter the granularity with the modify map approach as well - define a minimum alignment/length value
18:49 foster i.e., 128k alignment, 1mb, 4mb etc.
19:04 avati foster: if every alternate block is modified, modify map would be huge (compared to bit map of the same block size)
19:06 foster agree, I mean that given that scenario, you could increase the alignment such that modify map is shrunk to a single entry
19:07 foster (more for the afr case I suppose)
19:09 avati ah yes
20:55 badone joined #gluster-dev
22:48 awheele__ joined #gluster-dev

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