On 03/11/2013 02:40 PM, Jim Schutt wrote: >>> >> If you want I can attempt to duplicate my memory of the first >>> >> test I reported, writing the files today and doing the strace >>> >> tomorrow (with timestamps, this time). >>> >> >>> >> Also, would it be helpful to write the files with minimal logging, in >>> >> hopes of inducing minimal timing changes, then upping the logging >>> >> for the stat phase? >> > >> > Well that would give us better odds of not introducing failures of >> > any kind during the write phase, and then getting accurate >> > information on what's happening during the stats, so it probably >> > would. Basically I'd like as much logging as possible without >> > changing the states they system goes through. ;) > Hmmm, this is getting more interesting... > > I just did two complete trials where I built a file system, > did two sets of writes with minimal MDS logging, then > turned MDS logging up to 20 with MDS ms logging at 1 for > the stat phase. > > In each trial my strace'd find finished in < 10 seconds, > and there were no slow stat calls (they were taking ~19 ms > each). > > I'm going to do a third trial where I let things rest > overnight, after I write the files. That delay is the > only thing I haven't reproduced from my first trial.... As you suspected, that didn't make any difference either... That trial didn't reproduce the slow stat behavior. It turns out that the only way I can reliably reproduce the slow stat behavior right now is to turn MDS debugging up to 20. I've got another set of logs with MDS debug ms = 1, which I'll send via an off-list email. I still haven't figured out what made that first test exhibit this behavior, when I was using debug mds = 5. -- Jim > > -- Jim > > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
