From: Christoph Hellwig <hch@lst.de>
To: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@lst.de>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: trying to understand READ_META, READ_SYNC, WRITE_SYNC & co
Date: Mon, 21 Jun 2010 21:14:10 +0200 [thread overview]
Message-ID: <20100621191410.GA24213@lst.de> (raw)
In-Reply-To: <4C1FB5F7.3070908@kernel.dk>
On Mon, Jun 21, 2010 at 08:56:55PM +0200, Jens Axboe wrote:
> FWIW, Windows marks meta data writes and they go out with FUA set
> on SATA disks. And SATA firmware prioritizes FUA writes, it's essentially
> a priority bit as well as a platter access bit. So at least we have some
> one else using a meta data boost. I agree that it would be a lot more
> trivial to add the annotations if they didn't have scheduler impact
> as well, but I still think it's a sane thing.
And we still disable the FUA bit in libata unless people set a
non-standard module option..
> >> Reads are sync by nature in the block layer, so they don't get that
> >> special annotation.
> >
> > Well, we do give them this special annotation in a few places, but we
> > don't actually use it.
>
> For unplugging?
We use the explicit unplugging, yes - but READ_META also includes
REQ_SYNC which is not used anywhere.
> > But that leaves the question why disabling the idling logical for
> > data integrity ->writepage is fine? This gets called from ->fsync
> > or O_SYNC writes and will have the same impact as O_DIRECT writes.
>
> We have never enabled idling for those. O_SYNC should get a nice
> boost too, it just needs to be benchmarked and tested and then
> there would be no reason not to add it.
We've only started using any kind of sync tag last year in ->writepage in
commit a64c8610bd3b753c6aff58f51c04cdf0ae478c18 "block_write_full_page:
Use synchronous writes for WBC_SYNC_ALL writebacks", switching from
WRITE_SYNC to WRITE_SYNC_PLUG a bit later in commit
6e34eeddf7deec1444bbddab533f03f520d8458c "block_write_full_page: switch
synchronous writes to use WRITE_SYNC_PLUG"
Before that we used plain WRITE, which had the normal idling logic.
next prev parent reply other threads:[~2010-06-21 19:14 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-21 9:48 trying to understand READ_META, READ_SYNC, WRITE_SYNC & co Christoph Hellwig
2010-06-21 10:04 ` Jens Axboe
2010-06-21 11:04 ` Christoph Hellwig
2010-06-21 18:56 ` Jens Axboe
2010-06-21 19:14 ` Christoph Hellwig [this message]
2010-06-21 19:16 ` Jens Axboe
2010-06-21 19:20 ` Christoph Hellwig
2010-06-21 21:36 ` Vivek Goyal
2010-06-23 10:01 ` Christoph Hellwig
2010-06-24 1:44 ` Vivek Goyal
2010-06-25 11:03 ` Christoph Hellwig
2010-06-26 3:35 ` Vivek Goyal
2010-06-26 10:05 ` Christoph Hellwig
2010-06-26 11:20 ` Jens Axboe
2010-06-26 11:56 ` Christoph Hellwig
2010-06-27 15:44 ` Jeff Moyer
2010-06-29 9:06 ` Corrado Zoccolo
2010-06-29 12:30 ` Vivek Goyal
2010-06-29 12:30 ` Vivek Goyal
2010-06-30 15:30 ` Corrado Zoccolo
2010-06-30 15:30 ` Corrado Zoccolo
2010-06-26 9:25 ` Nick Piggin
2010-06-26 9:27 ` Christoph Hellwig
2010-06-26 10:10 ` Nick Piggin
2010-06-26 10:16 ` Christoph Hellwig
2010-06-21 18:52 ` Jeff Moyer
2010-06-21 18:58 ` Jens Axboe
2010-06-21 19:08 ` Jeff Moyer
2010-06-23 9:26 ` Christoph Hellwig
2010-06-21 20:25 ` Vivek Goyal
2010-06-23 10:02 ` Christoph Hellwig
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=20100621191410.GA24213@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=linux-fsdevel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.