Documentation: Remove mentioning of block barriers
Subsystems (2)
PATCH 1/1 Documentation: Remove mentioning of block barriers
Remove mentioning of block barriers since they were removed.
Signed-off-by Leonid V. Fedorenchik <[email protected]>
--- Documentation/block/biodoc.txt | 36 +++++++++--------------------------- 1 file changed, 9 insertions(+), 27 deletions(-)
Documentation/block/biodoc.txt +9 -27
@@ -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
Signature · 1 line
2.2.1
Quoted 3 lines · Leonid V. Fedorenchik
Remove mentioning of block barriers since they were removed.
Signed-off-by Leonid V. Fedorenchik <[email protected]>
The change looks fine. It would be nice to at least referenceDocumentation/block/writeback_cache_control.txt for description of REQ_FLUSH and REQ_FUA flags.
Honza
Quoted 68 lines
--- Documentation/block/biodoc.txt | 36 +++++++++--------------------------- 1 file changed, 9 insertions(+), 27 deletions(-)Documentation/block/biodoc.txt +9
-27@@ -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 improveSignature · 1 line
2.2.1
Signature · 2 lines
Jan Kara <[email protected]> SUSE Labs, CR
Quoted 3 lines · Leonid V. Fedorenchik
Remove mentioning of block barriers since they were removed.
Signed-off-by Leonid V. Fedorenchik <[email protected]>
Looks good.
Reviewed-by Christoph Hellwig <[email protected]>
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..
Quoted 1 line · On Fri, 13 Mar 2015 23:53:22 +0300 "Leonid V. Fedorenchik"…
Remove mentioning of block barriers since they were removed.
Applied to the docs tree.
Thanks,
jon
Quoted 6 lines · On Thu, 19 Mar 2015 14:57:27 -0600 Jonathan Corbet <[email protected]> wrote:
Quoted 1 line · On Fri, 13 Mar 2015 23:53:22 +0300 "Leonid V. Fedorenchik"…
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.
Quoted 4 lines
Thanks,
jon
Leonid V. Fedorenchik