linux-kernel - Re: REQ_FLUSH, REQ_FUA and open/close of block devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110522104448.GA20241@infradead.org>
Date:	Sun, 22 May 2011 06:44:49 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Alex Bligh <alex@...x.org.uk>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: REQ_FLUSH, REQ_FUA and open/close of block devices

On Sat, May 21, 2011 at 09:42:45AM +0100, Alex Bligh wrote:
> What I am concerned about is that relatively normal actions (e.g. unmount
> a filing system) do not appear to be flushing all data, even though I
> did "sync" then "umount". I suspect the sync is generating the FLUSH here,
> and nothing is flushing the umount writes. How can I know as a block
> device that I have to write out a (long lasting) writeback cache if
> I don't receive anything beyond the last WRITE?

In your case it seems like ext3 is doing something wrong.  If you
run the same on XFS, you should not only see the last real write
having FUA and FLUSH as it's a transaction commit, but also an
explicit cache flush when devices are closed from the filesystem
to work around issues like that.  But the raw block device node
really doesn't behave different from a file and shouldn't cause
any fsync on close.

Btw, using sync_file_range is a really bad idea.  It will not actually
flush the disk cache on the server, nor make sure metadata is commited in
case of a sparse or preallocated file, and thus does not implement
the FLUSH or FUA semantics correctly.

And btw, I'd like to know what makes sync_file_range so tempting,
even after I added documentation explaining why it's almost always
wrong to use it to the man page.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/