From: Jan Kara <jack@suse.cz>
To: "Leonid V. Fedorenchik" <leonidsbox@gmail.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
Mike Christie <michaelc@cs.wisc.edu>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Jens Axboe <axboe@fb.com>, Hannes Reinecke <hare@suse.de>,
Jan Kara <jack@suse.cz>, Christoph Hellwig <hch@lst.de>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Documentation: Remove mentioning of block barriers
Date: Sat, 14 Mar 2015 07:23:56 +0100 [thread overview]
Message-ID: <20150314062356.GA2096@quack.suse.cz> (raw)
In-Reply-To: <1426280002-11940-1-git-send-email-leonidsbox@gmail.com>
On Fri 13-03-15 23:53:22, Leonid V. Fedorenchik wrote:
> Remove mentioning of block barriers since they were removed.
>
> Signed-off-by: Leonid V. Fedorenchik <leonidsbox@gmail.com>
The change looks fine. It would be nice to at least reference
Documentation/block/writeback_cache_control.txt for description of
REQ_FLUSH and REQ_FUA flags.
Honza
> ---
> Documentation/block/biodoc.txt | 36 +++++++++---------------------------
> 1 file changed, 9 insertions(+), 27 deletions(-)
>
> diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt
> index 5aabc08..fd12c0d 100644
> --- a/Documentation/block/biodoc.txt
> +++ b/Documentation/block/biodoc.txt
> @@ -48,8 +48,7 @@ Description of Contents:
> - Highmem I/O support
> - I/O scheduler modularization
> 1.2 Tuning based on high level requirements/capabilities
> - 1.2.1 I/O Barriers
> - 1.2.2 Request Priority/Latency
> + 1.2.1 Request Priority/Latency
> 1.3 Direct access/bypass to lower layers for diagnostics and special
> device operations
> 1.3.1 Pre-built commands
> @@ -255,29 +254,12 @@ some control over i/o ordering.
> What kind of support exists at the generic block layer for this ?
>
> The flags and rw fields in the bio structure can be used for some tuning
> -from above e.g indicating that an i/o is just a readahead request, or for
> -marking barrier requests (discussed next), or priority settings (currently
> -unused). As far as user applications are concerned they would need an
> -additional mechanism either via open flags or ioctls, or some other upper
> -level mechanism to communicate such settings to block.
> -
> -1.2.1 I/O Barriers
> -
> -There is a way to enforce strict ordering for i/os through barriers.
> -All requests before a barrier point must be serviced before the barrier
> -request and any other requests arriving after the barrier will not be
> -serviced until after the barrier has completed. This is useful for higher
> -level control on write ordering, e.g flushing a log of committed updates
> -to disk before the corresponding updates themselves.
> -
> -A flag in the bio structure, BIO_BARRIER is used to identify a barrier i/o.
> -The generic i/o scheduler would make sure that it places the barrier request and
> -all other requests coming after it after all the previous requests in the
> -queue. Barriers may be implemented in different ways depending on the
> -driver. For more details regarding I/O barriers, please read barrier.txt
> -in this directory.
> -
> -1.2.2 Request Priority/Latency
> +from above e.g indicating that an i/o is just a readahead request, or priority
> +settings (currently unused). As far as user applications are concerned they
> +would need an additional mechanism either via open flags or ioctls, or some
> +other upper level mechanism to communicate such settings to block.
> +
> +1.2.1 Request Priority/Latency
>
> Todo/Under discussion:
> Arjan's proposed request priority scheme allows higher levels some broad
> @@ -906,8 +888,8 @@ queue and specific I/O schedulers. Unless stated otherwise, elevator is used
> to refer to both parts and I/O scheduler to specific I/O schedulers.
>
> Block layer implements generic dispatch queue in block/*.c.
> -The generic dispatch queue is responsible for properly ordering barrier
> -requests, requeueing, handling non-fs requests and all other subtleties.
> +The generic dispatch queue is responsible for requeueing, handling non-fs
> +requests and all other subtleties.
>
> Specific I/O schedulers are responsible for ordering normal filesystem
> requests. They can also choose to delay certain requests to improve
> --
> 2.2.1
>
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2015-03-14 6:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-13 20:53 [PATCH] Documentation: Remove mentioning of block barriers Leonid V. Fedorenchik
2015-03-14 6:23 ` Jan Kara [this message]
2015-03-16 12:26 ` Christoph Hellwig
2015-03-19 20:57 ` Jonathan Corbet
2015-03-23 19:16 ` Leonid V. Fedorenchik
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=20150314062356.GA2096@quack.suse.cz \
--to=jack@suse.cz \
--cc=axboe@fb.com \
--cc=corbet@lwn.net \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=leonidsbox@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=michaelc@cs.wisc.edu \
/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).