From: Alex Bligh <alex@alex.org.uk>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org, Alex Bligh <alex@alex.org.uk>
Subject: Re: REQ_FLUSH, REQ_FUA and open/close of block devices
Date: Sat, 21 May 2011 09:42:45 +0100 [thread overview]
Message-ID: <60FB7C5F40961417F1605595@nimrod.local> (raw)
In-Reply-To: <20110520122010.GA25628@infradead.org>
--On 20 May 2011 08:20:10 -0400 Christoph Hellwig <hch@infradead.org> wrote:
> On Thu, May 19, 2011 at 04:06:27PM +0100, Alex Bligh wrote:
>> Should a close() of a dirty block device result in a REQ_FLUSH?
>
> No, why would it? That's what fsync is for.
I had thought fsync() was meant to be implicit in a close of a raw device
though perhaps that's my faulty memory; I think you are saying it's
up to userspace to fix these; fair enough.
However, I'm also seeing writes to the device after the last flush when
the device is unmounted. Specifically, a sequence ending
mount -t ext3 -odata=journal,barrier=1 /dev/nbd0 /mnt
(cd /mnt ; tar cvzf /dev/null . ; sync) 2>&1 >/dev/null
dbench -D /mnt 1 &
sleep 10
killall dbench
sleep 2
killall -KILL dbench
sync
umount /mnt
produces these commands (at the end):
Sending command: NBD_CMD_WRITE [NONE] (0x00000001)
Sending command: NBD_CMD_WRITE [NONE] (0x00000001)
Sending command: NBD_CMD_FLUSH [NONE] (0x00000003)
Sending command: NBD_CMD_WRITE [FUA] (0x00010001)
Sending command: NBD_CMD_WRITE [NONE] (0x00000001)
Sending command: NBD_CMD_WRITE [NONE] (0x00000001)
Sending command: NBD_CMD_WRITE [NONE] (0x00000001)
Sending command: NBD_CMD_WRITE [NONE] (0x00000001)
Sending command: NBD_CMD_WRITE [NONE] (0x00000001)
Sending command: NBD_CMD_WRITE [NONE] (0x00000001)
Sending command: NBD_CMD_WRITE [NONE] (0x00000001)
Sending command: NBD_CMD_WRITE [NONE] (0x00000001)
Sending command: NBD_CMD_WRITE [NONE] (0x00000001)
(I'm testing this out by adding flush and fua support to nbd, see
git.alex.org.uk if this is interesting).
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?
--
Alex Bligh
next prev parent reply other threads:[~2011-05-21 8:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-19 15:06 Alex Bligh
2011-05-20 12:20 ` Christoph Hellwig
2011-05-21 8:42 ` Alex Bligh [this message]
2011-05-22 10:44 ` Christoph Hellwig
2011-05-22 11:17 ` Alex Bligh
2011-05-22 11:26 ` Christoph Hellwig
2011-05-22 12:00 ` Alex Bligh
2011-05-22 12:04 ` Christoph Hellwig
2011-05-22 16:56 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60FB7C5F40961417F1605595@nimrod.local \
--to=alex@alex.org.uk \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®