From: Tejun Heo <tj@kernel.org>
To: Philipp Reisner <philipp.reisner@linbit.com>
Cc: Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
linux-kernel@vger.kernel.org, drbd-dev@lists.linbit.com
Subject: Re: FLUSH/FUA documentation & code discrepancy
Date: Tue, 4 Sep 2012 15:46:20 -0700 [thread overview]
Message-ID: <20120904224620.GB9092@dhcp-172-17-108-109.mtv.corp.google.com> (raw)
In-Reply-To: <8439412.RChiDciQdh@fat-tyre>
Hello,
On Tue, Sep 04, 2012 at 02:32:01PM +0200, Philipp Reisner wrote:
> 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.
Currently, FLUSH/FUA doesn't enforce any ordering requirement. File
systems are responsible for draining all writes which have to happen
before and not issue further writes which should come after. The use
of SOFTBARRIER there is mostly historical. I *suspect* we should be
able to drop that as RQ_NOMERGE_FLAGS already contain FLUSH and FUA.
Not really looked through it tho.
> 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.
So, yeah, it is no-op by intention. We probably should make the
documentation clearer.
Thanks.
--
tejun
next prev parent reply other threads:[~2012-09-04 22:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-04 12:32 FLUSH/FUA documentation & code discrepancy Philipp Reisner
2012-09-04 22:46 ` Tejun Heo [this message]
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=20120904224620.GB9092@dhcp-172-17-108-109.mtv.corp.google.com \
--to=tj@kernel.org \
--cc=axboe@kernel.dk \
--cc=drbd-dev@lists.linbit.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=philipp.reisner@linbit.com \
/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).