LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH] Documentation: Remove mentioning of block barriers
@ 2015-03-13 20:53 Leonid V. Fedorenchik
  2015-03-14  6:23 ` Jan Kara
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Leonid V. Fedorenchik @ 2015-03-13 20:53 UTC (permalink / raw)
  To: Jonathan Corbet
  Cc: Mike Christie, Martin K. Petersen, Jens Axboe, Hannes Reinecke,
	Jan Kara, Christoph Hellwig, linux-doc, linux-kernel,
	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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Documentation: Remove mentioning of block barriers
  2015-03-13 20:53 [PATCH] Documentation: Remove mentioning of block barriers Leonid V. Fedorenchik
@ 2015-03-14  6:23 ` Jan Kara
  2015-03-16 12:26 ` Christoph Hellwig
  2015-03-19 20:57 ` Jonathan Corbet
  2 siblings, 0 replies; 5+ messages in thread
From: Jan Kara @ 2015-03-14  6:23 UTC (permalink / raw)
  To: Leonid V. Fedorenchik
  Cc: Jonathan Corbet, Mike Christie, Martin K. Petersen, Jens Axboe,
	Hannes Reinecke, Jan Kara, Christoph Hellwig, linux-doc,
	linux-kernel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Documentation: Remove mentioning of block barriers
  2015-03-13 20:53 [PATCH] Documentation: Remove mentioning of block barriers Leonid V. Fedorenchik
  2015-03-14  6:23 ` Jan Kara
@ 2015-03-16 12:26 ` Christoph Hellwig
  2015-03-19 20:57 ` Jonathan Corbet
  2 siblings, 0 replies; 5+ messages in thread
From: Christoph Hellwig @ 2015-03-16 12:26 UTC (permalink / raw)
  To: Leonid V. Fedorenchik
  Cc: Jonathan Corbet, Mike Christie, Martin K. Petersen, Jens Axboe,
	Hannes Reinecke, Jan Kara, Christoph Hellwig, linux-doc,
	linux-kernel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Documentation: Remove mentioning of block barriers
  2015-03-13 20:53 [PATCH] Documentation: Remove mentioning of block barriers Leonid V. Fedorenchik
  2015-03-14  6:23 ` Jan Kara
  2015-03-16 12:26 ` Christoph Hellwig
@ 2015-03-19 20:57 ` Jonathan Corbet
  2015-03-23 19:16   ` Leonid V. Fedorenchik
  2 siblings, 1 reply; 5+ messages in thread
From: Jonathan Corbet @ 2015-03-19 20:57 UTC (permalink / raw)
  To: Leonid V. Fedorenchik
  Cc: Mike Christie, Martin K. Petersen, Jens Axboe, Hannes Reinecke,
	Jan Kara, Christoph Hellwig, linux-doc, linux-kernel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Documentation: Remove mentioning of block barriers
  2015-03-19 20:57 ` Jonathan Corbet
@ 2015-03-23 19:16   ` Leonid V. Fedorenchik
  0 siblings, 0 replies; 5+ messages in thread
From: Leonid V. Fedorenchik @ 2015-03-23 19:16 UTC (permalink / raw)
  To: Jonathan Corbet
  Cc: Mike Christie, Martin K. Petersen, Jens Axboe, Hannes Reinecke,
	Jan Kara, Christoph Hellwig, linux-doc, linux-kernel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2015-03-23 19:16 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-13 20:53 [PATCH] Documentation: Remove mentioning of block barriers Leonid V. Fedorenchik
2015-03-14  6:23 ` Jan Kara
2015-03-16 12:26 ` Christoph Hellwig
2015-03-19 20:57 ` Jonathan Corbet
2015-03-23 19:16   ` Leonid V. Fedorenchik

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).