Messages in this thread | | | Date | Mon, 23 May 2011 18:39:23 +0100 | From | Alex Bligh <> | Subject | Re: BUG: Failure to send REQ_FLUSH on unmount on ext3, ext4, and FS in general |
| |
Jan,
--On 23 May 2011 19:29:06 +0200 Jan Kara <jack@suse.cz> wrote:
> I wish it was this simple ;) The trouble is that clever filesystems - > e.g. xfs, ext4 - will send the flush when it's needed (after a transaction > commit). So sending it after flushing the device (which happens from > generic sync code) would result in two flushes instead of one - not good > for performance (although these days when we do merging of flush requests > the result need not be that bad). > > The fs might indicate whether it handles barriers itself or whether it > wants VFS to handle it but that's where it's gets a bit complicated / > controversial ;).
Well, to "fix" sync(), one could simply look at whether the file system had ever sent a REQ_FLUSH or REQ_FUA since that FS was mounted. If there has been one, assume the FS is taking responsibility for sending them.
I'm presuming that if just umount() were altered to do a REQ_FLUSH, the potential presence of 2 sync()s would not be too offensive, as unmount isn't exactly time critical, and as Christoph pointed out in the other thread, a REQ_FLUSH when the write cache has recently been emptied isn't going to take long.
>> Would there be any interested in these patches if I cooked them up, >> or did they die because of opposition before rather than apathy? > > I guess you might come with some proposal and post it to linux-fsdevel > (include Al Viro and Christoph Hellwig in CC) and see what happens...
Ah, fsdevel not here. OK. Partly I'd like to understand whether sync() not flushing write caches on barrier-less file systems is a good thing or a bad thing. I know barriers are better, but if writing to (e.g.) FAT32, I'm betting there is little prospect of barrier support.
-- Alex Bligh
| |