Thread (2 messages) 2 messages, 2 authors, 2012-02-08

Re: [PATCH 3/3] filemap: don't call generic_write_sync for -EIOCBQUEUED

From: Jeff Moyer <hidden>
Date: 2012-02-07 20:39:06
Also in: linux-fsdevel, linux-xfs

Christoph Hellwig [off-list ref] writes:
On Mon, Feb 06, 2012 at 11:33:29AM -0500, Jeff Moyer wrote:
quoted
quoted
code, right? Before that we'd drain the IO queue when cache flush is issued
and thus effectively wait for IO completion...
Right, though hch seems to think even then the problem existed.
I was wrong, using -o barrier it didn't.  That was however not something
people using O_SYNC heavy production loads would do, they'd use disabled
caches and nobarrier.
quoted
quoted
Also I was thinking whether we couldn't implement the fix in VFS. Basically
it would be the same like the fix for ext4. Like having a per-sb workqueue
and queue work calling generic_write_sync() from end_io handler when the
file is O_SYNC? That would solve the issue for all filesystems...
Well, that would require buy-in from the other file system developers.
What do the XFS folks think?
I don't think using that code for XFS makes sene.  But just like
generic_write_sync there's no reason it can't be added to generic code,
just make sure only generic_file_aio_write/__generic_file_aio_write use
it, but generic_file_buffered_write and generic_file_direct_write stay
clear of it.
ext4_file_write (ext4's .aio_write routine) calls into
generic_file_aio_write.  So, I don't think we can generalize that this
routine means that the file system doesn't install its own endio
handler.  What's more, we'd have to pass an endio routine down the call
stack quite a ways.  In all, I think that would be an uglier solution to
the problem.  Did I miss something?

Cheers,
Jeff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help