[PATCH] Documentation: Remove mentioning of block barriers

[Leonid V. Fedorenchik]

Remove mentioning of block barriers since they were removed.

Signed-off-by: Leonid V. Fedorenchik <leoni...@gmail.com>
---
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Jan Kara]

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 <leoni...@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

Jan Kara <ja...@suse.cz>
SUSE Labs, CR

[Christoph Hellwig]

On Fri, Mar 13, 2015 at 11:53:22PM +0300, Leonid V. Fedorenchik wrote:
> Remove mentioning of block barriers since they were removed.
>
> Signed-off-by: Leonid V. Fedorenchik <leoni...@gmail.com>

Looks good.

Reviewed-by: Christoph Hellwig <h...@lst.de>

Re Jans comments: this document is structurally out of date, as it's
framed aroudn the transition of the 2.4 to 2.5 block layer code.
Replacing it with something that just describes the current code
would be nice, nut not something I would want to bureden on someone
just removing the now incorrect parts of it.

And with blk-mq this is even more out of date now..

[Jonathan Corbet]

On Fri, 13 Mar 2015 23:53:22 +0300
"Leonid V. Fedorenchik" <leoni...@gmail.com> wrote:

> Remove mentioning of block barriers since they were removed.

Applied to the docs tree.

Thanks,

jon

[Leonid V. Fedorenchik]

On Thu, 19 Mar 2015 14:57:27 -0600
Jonathan Corbet <cor...@lwn.net> wrote:

> On Fri, 13 Mar 2015 23:53:22 +0300
> "Leonid V. Fedorenchik" <leoni...@gmail.com> wrote:
>
> > Remove mentioning of block barriers since they were removed.
>
> Applied to the docs tree.

Thank you. Regarding Jan Kara's comment, I'll send it as another patch
when I figure out where is the best place to put additional
information.

>
> Thanks,
>
> jon


Leonid V. Fedorenchik