From: Philipp Reisner <philipp.reisner@linbit.com>
To: Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
Tejun Heo <tj@kernel.org>
Cc: linux-kernel@vger.kernel.org, drbd-dev@lists.linbit.com
Subject: FLUSH/FUA documentation & code discrepancy
Date: Tue, 04 Sep 2012 14:32:01 +0200 [thread overview]
Message-ID: <8439412.RChiDciQdh@fat-tyre> (raw)
Hi,
I think commit 1e87901e18 was wrong. Starting with that commit the REQ_FLUSH
and REQ_FUA bits get stripped away if the queue does not advertise REQ_FLUSH
or REQ_FUA support.
But the REQ_FLUSH bit is also tested for when not merging requests
(blk_queue_bio()) or when it comes to the elevator (blk_flush_plug_list()).
So, since this patch the elevator reorders write requests on queues that
do not have REQ_FLUSH or REQ_FUA set.
While on queues that have REQ_FLUSH or REQ_FUA set, the elevator does
not reorder writes across FLUSHes.
The Documentation/block/writeback_cache_control.txt file says:
--snip--
Implementation details for filesystems
--------------------------------------
Filesystems can simply set the REQ_FLUSH and REQ_FUA bits and do not have to
worry if the underlying devices need any explicit cache flushing and how
the Forced Unit Access is implemented. The REQ_FLUSH and REQ_FUA flags
may both be set on a single bio.
--snap--
I have the impression every file system lets IO drain, and issues a
flush afterwards with the blkdev_issue_flush() function. BTW that
function turns into a non-obvious no-op as soon as the queue does not
have the REQ_FUA or REQ_FLUSH bits set. It does not look like it is
a no-op by intention.
The file systems seem to be all fine, only in DRBD we have a mode were
we depend on REQ_FUA/REQ_FLUSH requests being real boundaries for reordering
of writes. This is broken since the mentioned commit as we recently found out.
I suggest that either this commit gets reverted, or the documentation
is updated. I am ready to prepare such a patch, but I need directions
how it should be fixed.
Best regards,
Phil
next reply other threads:[~2012-09-04 12:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-04 12:32 Philipp Reisner [this message]
2012-09-04 22:46 ` FLUSH/FUA documentation & code discrepancy Tejun Heo
2012-09-05 8:44 ` [Drbd-dev] " Philipp Reisner
2012-09-05 8:49 ` Tejun Heo
2012-09-05 10:07 ` Lars Ellenberg
2012-09-06 21:29 ` Tejun Heo
2012-09-07 8:42 ` Lars Ellenberg
2012-09-10 22:54 ` Tejun Heo
2012-09-10 23:06 ` Tejun Heo
2012-09-10 23:12 ` Kent Overstreet
2012-09-10 23:31 ` Kent Overstreet
2012-09-11 5:58 ` NeilBrown
2012-09-11 8:25 ` Lars Ellenberg
2012-09-11 14:41 ` Vivek Goyal
2012-09-12 18:58 ` Tejun Heo
2012-09-12 23:12 ` Joseph Glanville
2012-09-12 23:20 ` Tejun Heo
2012-09-12 23:53 ` Joseph Glanville
2012-09-13 0:17 ` Joseph Glanville
2012-09-13 3:10 ` Joseph Glanville
2012-09-13 19:25 ` Tejun Heo
2012-09-11 14:34 ` Vivek Goyal
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=8439412.RChiDciQdh@fat-tyre \
--to=philipp.reisner@linbit.com \
--cc=axboe@kernel.dk \
--cc=drbd-dev@lists.linbit.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@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;
as well as URLs for NNTP newsgroup(s).