Colin Walters wrote:
>
> Steve Lord <lord@xxxxxxx> writes:
>
> > 2. An individual thread doing a write in XFS has no way of knowing
> > or predicting what else may just of happened, or be about to
> > happen on the system. You cannot say 'I will write my data now
> > because the system is idle', there may be a couple of Gbytes of
> > I/O about to come in from another source.
>
> Why couldn't the kernel keep some statistics about disk usage, and use
> those to make an educated guess as to whether or not we should write
> out the data immediately?
>
> I appreciate that XFS can deal with gigabytes of I/O, but such an
> event is very unlikely on my laptop :)
Again, this really isn't XFS-specific. The bdflush daemon pushes out
metadata every 5 seconds, data every 30 (by default). You'll see this
same behavior with ext2.
I think a big reason that people are seeing it "more" with XFS is that
after recovery, a file exists with "nulls" in it, which looks like
corruption. Based on the quick experiment in my previous email, I think
the difference is that with ext2, the user would never even see the
file, so they may not notice. "Blissfully unaware" as they say. :)
Regarding prediction for when to write, that's a whole different
ballpark. It would be pretty tough to "predict" that there will be no
other I/O's happening in the next 2 seconds, so now is a good time to
write that 5 byte file...
-Eric
--
Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
sandeen@xxxxxxx SGI, Inc.
|