1
0
Fork 0

Documentation: Remove mentioning of block barriers

Remove mentioning of block barriers since they were removed.

Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Leonid V. Fedorenchik <leonidsbox@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
wifi-calibration
Leonid V. Fedorenchik 2015-03-13 23:53:22 +03:00 committed by Jonathan Corbet
parent d50ca07863
commit 8962786ce3
1 changed files with 8 additions and 26 deletions

View File

@ -48,8 +48,7 @@ Description of Contents:
- Highmem I/O support - Highmem I/O support
- I/O scheduler modularization - I/O scheduler modularization
1.2 Tuning based on high level requirements/capabilities 1.2 Tuning based on high level requirements/capabilities
1.2.1 I/O Barriers 1.2.1 Request Priority/Latency
1.2.2 Request Priority/Latency
1.3 Direct access/bypass to lower layers for diagnostics and special 1.3 Direct access/bypass to lower layers for diagnostics and special
device operations device operations
1.3.1 Pre-built commands 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 ? 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 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 from above e.g indicating that an i/o is just a readahead request, or priority
marking barrier requests (discussed next), or priority settings (currently settings (currently unused). As far as user applications are concerned they
unused). As far as user applications are concerned they would need an would need an additional mechanism either via open flags or ioctls, or some
additional mechanism either via open flags or ioctls, or some other upper other upper level mechanism to communicate such settings to block.
level mechanism to communicate such settings to block.
1.2.1 I/O Barriers 1.2.1 Request Priority/Latency
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
Todo/Under discussion: Todo/Under discussion:
Arjan's proposed request priority scheme allows higher levels some broad 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. to refer to both parts and I/O scheduler to specific I/O schedulers.
Block layer implements generic dispatch queue in block/*.c. 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 requeueing, handling non-fs
requests, requeueing, handling non-fs requests and all other subtleties. requests and all other subtleties.
Specific I/O schedulers are responsible for ordering normal filesystem Specific I/O schedulers are responsible for ordering normal filesystem
requests. They can also choose to delay certain requests to improve requests. They can also choose to delay certain requests to improve