On Wed, Jul 16, 2008 at 03:58:55PM -0600, Chris Torek wrote:
> >Well, you are pretty much on your own, then. Really, we cannot help
> >diagnose problems on old kernels with a random set of backported
> >patches in them.
>
> Definitely understood. I just wanted to ask that original
> question, really. I had assumed that the file system itself
> had to start any dirty-page writes, having missed the top level
> filemap_fdatawrite() call.
>
> We finally got a test case and did a bunch of analysis, and it
> turns out that the DB software is missing an fsync() call. Of
> course XFS won't fsync the file if you don't *ask* it to!
Yes, that would help ;)
Thanks for following up and letting us know you found the
problem.
> As long as I am sending mail, there is something else I am curious
> about though. While this is not XFS specific, I wonder if there
> is any desire to have different background write frequencies on
> different file systems. By default, mm/page-writeback.c will start
> writebacks after a 30-second delay. One can tune this to any other
> number (via /proc/sys/vm/dirty_{expire,writeback}_centisecs), but
> this affects the entire system. It might be useful to be able
> to tune this per-FS instead.
Wouldn't be too difficult, but really if you have data that needs
to go to disk quickly from a given application then the application
should be triggering the flush. e.g. іssuing
posix_fadvise(fd, ...., POSIX_FADV_DONTNEED) will trigger an
immediate async flush of the file....
> (On the other hand, perhaps if one really wants one's data journaled,
> one should just use a data-journaling file system....)
Or use the sync mount option.....
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
|