[PATCH] Documentation: drop stale I/O barrier descriptions
From: Liu Bo
Date: Tue Dec 27 2011 - 22:57:08 EST
Sorry for double mails, missing to cc LKML...
Since we've applied writeback_cache_control.txt and removed barrier.txt,
drop the related descriptions in biodoc.txt.
Signed-off-by: Liu Bo <liubo2009@xxxxxxxxxxxxxx>
Documentation/block/biodoc.txt | 21 ++-------------------
1 files changed, 2 insertions(+), 19 deletions(-)
diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt
index e418dc0..2ce818f 100644
@@ -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
1.3.1 Pre-built commands
@@ -261,23 +260,7 @@ 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
+1.2.1 Request Priority/Latency
Arjan's proposed request priority scheme allows higher levels some broad
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/