Camelia, the Perl 6 bug

IRC log for #gluster-dev, 2013-07-25

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

All times shown according to UTC.

Time Nick Message
00:25 hagarth joined #gluster-dev
00:52 yinyin joined #gluster-dev
01:20 bala joined #gluster-dev
01:49 yinyin joined #gluster-dev
01:50 lpabon joined #gluster-dev
01:50 lpabon joined #gluster-dev
02:06 nickw joined #gluster-dev
02:48 lalatenduM joined #gluster-dev
03:02 kkeithley joined #gluster-dev
03:04 shubhendu joined #gluster-dev
03:09 kshlm joined #gluster-dev
03:30 hagarth joined #gluster-dev
03:39 bulde joined #gluster-dev
03:45 bharata-rao joined #gluster-dev
04:01 mohankumar joined #gluster-dev
04:09 Technicool joined #gluster-dev
05:05 tg2 joined #gluster-dev
05:20 bala joined #gluster-dev
05:44 lalatenduM joined #gluster-dev
05:45 lalatenduM joined #gluster-dev
06:27 bulde joined #gluster-dev
06:30 bulde1 joined #gluster-dev
06:38 shubhendu joined #gluster-dev
06:56 asias joined #gluster-dev
06:57 vshankar joined #gluster-dev
07:11 asias joined #gluster-dev
07:28 lalatenduM joined #gluster-dev
07:54 bulde joined #gluster-dev
08:23 bulde joined #gluster-dev
08:42 shubhendu joined #gluster-dev
09:01 shubhendu joined #gluster-dev
09:24 bala joined #gluster-dev
09:55 bulde joined #gluster-dev
10:09 blues-man joined #gluster-dev
10:39 shubhendu joined #gluster-dev
11:42 edward1 joined #gluster-dev
11:47 bala joined #gluster-dev
11:50 shubhendu joined #gluster-dev
12:52 deepakcs joined #gluster-dev
13:53 bala joined #gluster-dev
14:03 wushudoin joined #gluster-dev
14:17 sghosh joined #gluster-dev
15:06 hagarth joined #gluster-dev
15:07 lalatenduM joined #gluster-dev
15:16 puebele joined #gluster-dev
15:21 bala joined #gluster-dev
15:26 puebele2 joined #gluster-dev
16:29 avati left #gluster-dev
16:30 avati joined #gluster-dev
16:32 avati bfoster: ping?
16:33 foster avati: pong
16:34 avati foster: hey..
16:34 avati had a couple of questions
16:35 foster sure
16:35 avati about fsync performance on XFS - how hard (or acceptable) would it be to get an io_submit() interface for bulk fsync?
16:36 foster hmm, technically it might not be that hard
16:36 foster but politically it might be hard
16:37 avati if we present numbers along with the case, it might be convincing, no?
16:37 avati *perf numbers
16:38 foster perhaps, it could be a worthy experiment in any case
16:38 avati i am still exploring various approaches to reliably write small files. the other approach suggested by dchinner was to use O_DORECT( with aio)
16:39 foster maybe it spawns a discussion if nothing else, and the performance result is positive
16:39 avati but if we're creating small files, it is extremely unlikely that the file size will be a multiple of 512 bytes
16:40 foster hmm, yeah. O_DIRECT is typically used with applications with more control over what they're writing, no?
16:40 foster do write sizes have to be sector aligned, or just write offsets?
16:41 avati yeah.. dchinner was suggesting that O_DIRECT is probably the most efficient way to get a lot of small files reliably written.. i was wondering if there is something i was missing about writing non-512 multiple size in O_DIRECT on xfs
16:41 avati like maybe write full sector size by padding up to next 512 boundary and truncate ?
16:42 avati foster: yes, O_DIRECT on xfs seems to require 512 aligned offset in file, 512 aligned memory and 512 multiple size
16:43 foster yeah it seems so, according to a quick test
16:43 lpabon joined #gluster-dev
16:44 avati can you think of some way to utilize O_DIRECT with small files for efficiency? (would truncating the file right after write be stupidly inefficient?)
16:46 foster we'd probably have to test the effect of a truncate
16:46 foster though I'd wonder too if the truncate reintroduces the need for fsync :P
16:47 avati :D
16:48 foster how much performance did we get back from the batched fsync approach?
16:48 avati not a lot :|
16:49 foster yeah, I hacked on it a decent amount as well, trying to use multiple threads, etc. I could reduce log flushes but still couldn't get much of a measurable perf. improvement :/
16:50 avati strictly speaking, we don't need fsync (i.e, no need to "push" data to disk) - we just need some way to get notified when writes get stabilized (in its natural course of time)
16:51 avati unfortunately there doesn't seem to be an interface to expose that, fsync is all we have as the closest fit for the requirement :|
16:52 hagarth bfoster: did anybody talk to you about the changed quota design today?
16:52 foster avati: right. even if we had the aio_fsync thing, we'd still have to flush out data I think
16:53 foster hagarth: i had a chat with kp and a few others yesterday sometime
16:53 hagarth foster: there has been (yet another) update today ;)
16:53 foster avati: so I guess there's a question on how much improvement is to be had there as well
16:53 avati foster: the hope is aio_submit would batch a lot of files into a single log flush
16:54 foster hagarth: oh :o
16:54 hagarth foster: will send out an email in a bit
16:54 foster avati: yeah my understanding is it would allow the log to behave "naturally" for metadata, but we'd still have to flush the file data right?
16:57 avati foster: yes, as long as the minimized count of log flushes decreases the side-effet on unrelated ssycalls (where otherwise lot of fsyncs would have a bad effect) we should be good
16:58 avati for sustained steady operation flushing of data to disk is inevitable.. the "natural course" (without fsync intervention) is efficient w.r.t unrelated create()s etc. - which is the goal to be achieved
16:59 foster we could actually test that from a perf. perspective I think, do we have any tests against current afr only doing fdatasync()s?
17:00 avati ben's small file perf test is what we're using for comparison
17:02 foster ok
17:03 foster a quick look at xfs_file_fsync() suggests that would emulate the behavior, flush the data and skip the log force
17:03 avati what would emulate the behavior?
17:04 foster of what we think aio_fsync() would behave like
17:04 avati ah ok
17:05 foster iow, if afr performance with fdatasync() only is bad, aio_fsync() probably wouldn't be any better
17:05 foster if perf is good, it might be worth the experiment
17:05 avati wouldn't bulk io_submit() result in fewer log flushes for stabilizing the same number of files?
17:07 avati (as compared to fsync() on every file)
17:07 foster I think so, I'm just wary in that I've been able to reduce log flushes to no measurable benefit
17:07 avati hmm ok
17:09 foster unless you think for some reason a bulk io_submit() would lead to much better performance than many fdatasync() calls
17:10 foster it makes sense that would reduce CPU usage, but is that our bottleneck here?
17:11 avati the bottleneck is the transaction engine. while the written data might get written in roughly the same amount of time, the hope is that the bad side effect on unrelated creates will now be reduced because of fewer log flushes
17:12 avati it may not be the case, maybe just my wrong understanding
17:13 foster it's probably worth an fdatasync() test then, at least we narrow down the problem
17:31 lalatenduM joined #gluster-dev
19:15 Technicool joined #gluster-dev
19:18 a2 joined #gluster-dev
19:21 hagarth joined #gluster-dev
19:31 puebele1 joined #gluster-dev
19:55 Technicool joined #gluster-dev
20:25 Technicool joined #gluster-dev
20:56 badone joined #gluster-dev
22:35 _ilbot joined #gluster-dev
22:35 Topic for #gluster-dev is now Gluster Development Channel - http://gluster.org | For general chat go to #gluster | Patches - http://review.gluster.org/ | Channel Logs - https://botbot.me/freenode/gluster-dev/ & http://irclog.perlgeek.de/gluster-dev/
23:02 asias joined #gluster-dev
23:54 badone joined #gluster-dev

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