Re: BUG: Failure to send REQ_FLUSH on unmount on ext3, ext4, and FSin general

From: Alex Bligh
Date: Mon May 23 2011 - 13:09:26 EST


--On 23 May 2011 17:55:50 +0200 Jan Kara <jack@xxxxxxx> wrote:

But quite aside from the question of whether the FS supports barriers,
should the kernel itself (rather than the FS) not be sending REQ_FLUSH on
an unmount as the last thing that happens? IE shouldn't we see a flush
even on (say) ext2 which is never going to support barriers. If the
kernel itself generated a REQ_FLUSH for the block device, this would keep
filesystems that don't support barriers safe provided the unmount
completed successfully and would have no impact on ones that had already
flushed the write-behind cache.

Yes, I think that generic VFS helpers should send barriers in cases
where it makes sense and umount is one of them. There even have been some
attempts to do so if I recall right but they didn't go anywhere.

Indeed I think even doing sync() on ext3 with default options does not
send a flush to the write cache. I had a quick look at the code (which
has got rather more complicated since the umount syscall moved from
super.c to namespace.c) and it seemed to me the best thing to do would
be for sync() on a block device to send a REQ_FLUSH to that device at
the end (assuming the comment about sync actually completing I/O rather
than merely initiating it still holds), and to ensure umount is calling

Would there be any interested in these patches if I cooked them up,
or did they die because of opposition before rather than apathy?

Alex Bligh
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at