On Sun, Apr 5, 2009 at 1:05 AM, Lelsie Rhorer <lrhorer@xxxxxxxxxxx> wrote: >> Alternate theory - serious fsync performance issue >> >> I don't know if it's related, but there is a lot of recent discussion >> related to fsync causing large delays in ext3. Linus is saying his >> highspeed SDD is seeing multisecond delays. He is very frustrated >> because the SDD should be more or less instantaneous. >> >> The current thread is http://markmail.org/message/adiyz3lri6tlueaf >> >> In one of the other threads I saw someone saying that in one test they >> had a fsync() call take minutes to return. Apparently no one yet >> fully understands what is going on. Seems like something that could >> in some way be related to what you are seeing. > > Well, it could be. I tried flushing the cashes numerous times while > testing, but I never could see it made a difference one way or the other. > In a separate thread you said it was reiser and what I have seen discussed is ext3, so you may be safe from that bug. As to flushing caches, I don't think that is the same thing. This bug specifically impacts fsyncs on a small file while a heavy i/o load is underway via other processes. The elevators were being discussed as part of the problem and fsync triggers different elevator logic than sync or drop_caches does. Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
