[PATCH] Documentation: update block/biodoc.txt coverage of writeback control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



BIO_BARRIER was removed a while ago, and barrier.txt was removed in
04ccc65cd1f57aee861708e08cd2272c5a0d088c. Replace the section referring
to those with a summary of writeback_cache_control.txt and a pointer to
it.

Signed-off-by: Geoffrey Thomas <gthomas@xxxxxxxxxxxx>
Cc: Christoph Hellwig <hch@xxxxxx>
Cc: Jens Axboe <axboe@xxxxxxxxx>
---

Let me know if I got this text right -- I don't pretend to be familiar with any of this, and simply just noticed this while reading the documentation to try to understand it.

 Documentation/block/biodoc.txt |   49 ++++++++++++++++++----------------------
 1 file changed, 22 insertions(+), 27 deletions(-)

diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt
index 8df5e8e..9ae16ed 100644
--- a/Documentation/block/biodoc.txt
+++ b/Documentation/block/biodoc.txt
@@ -48,7 +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.1 Volatile writeback cache control
 	1.2.2 Request Priority/Latency
   1.3 Direct access/bypass to lower layers for diagnostics and special
       device operations
@@ -256,26 +256,26 @@ 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
+marking writeback 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
+1.2.1 Volatile writeback cache control

-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.
+In order to ensure consistency of journaled filesystems and implement
+fsync and similar operations, the block layer provides two methods for
+synchronizing volatile writeback caches to non-volatile storage. Both
+are invoked via flags on an i/o operation. The first flag, REQ_FLUSH,
+requires that all previously completed writes be reach to non-volatile
+storage before this i/o starts (i.e., the volatile cache is flushed).
+The second, FUA (Forced Unit Access), requires that this write reaches
+non-volatile storage before signaling completion.

-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.
+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. For more details about usage and implementation, see the
+file writeback_cache_control.txt in this directory.

 1.2.2 Request Priority/Latency

@@ -815,19 +815,14 @@ tag number to the associated request. These are, in no particular order:
 Internally, block manages tags in the blk_queue_tag structure:

 	struct blk_queue_tag {
-		struct request **tag_index;	/* array or pointers to rq */
-		unsigned long *tag_map;		/* bitmap of free tags */
-		struct list_head busy_list;	/* fifo list of busy tags */
-		int busy;			/* queue depth */
-		int max_depth;			/* max queue depth */
+		struct request **tag_index;	/* map of busy tags */
+		unsigned long *tag_map;		/* map of free/busy tags */
+		int busy;			/* current depth */
+		int max_depth;			/* what we will send to device */
+		int real_max_depth;		/* what the array can hold */
+		atomic_t refcnt;		/* map can be shared */
 	};

-Most of the above is simple and straight forward, however busy_list may need
-a bit of explaining. Normally we don't care too much about request ordering,
-but in the event of any barrier requests in the tag queue we need to ensure
-that requests are restarted in the order they were queue. This may happen
-if the driver needs to use blk_queue_invalidate_tags().
-
 Tagging also defines a new request flag, REQ_QUEUED. This is set whenever
 a request is currently tagged. You should not use this flag directly,
 blk_rq_tagged(rq) is the portable way to do so.
@@ -911,7 +906,7 @@ 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
+The generic dispatch queue is responsible for properly processing writeback
 requests, requeueing, handling non-fs requests and all other subtleties.

 Specific I/O schedulers are responsible for ordering normal filesystem
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux