[PATCH] Documentation: Remove mentioning of block barriers

[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 <leonidsbox@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

Re: [PATCH] Documentation: Remove mentioning of block barriers

[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 <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

Re: [PATCH] Documentation: Remove mentioning of block barriers

[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 <leonidsbox@gmail.com>

Looks good.

Reviewed-by: Christoph Hellwig <hch@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..

Re: [PATCH] Documentation: Remove mentioning of block barriers

[Jonathan Corbet]

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

> Remove mentioning of block barriers since they were removed.

Applied to the docs tree.

Thanks,

jon

Re: [PATCH] Documentation: Remove mentioning of block barriers

[Leonid V. Fedorenchik]

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

> On Fri, 13 Mar 2015 23:53:22 +0300
> "Leonid V. Fedorenchik" <leonidsbox@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