zloop fixes and improvements #374
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Author
|
Upstream branch: 6da43bb |
blktests-ci
bot
force-pushed
the
linus-master_base
branch
from
83d3e2f to
00d5e5c
Compare
Author
|
Upstream branch: f824272 |
blktests-ci
bot
force-pushed
the
series/1023830=>linus-master
branch
from
2ca62c3 to
6fca0f5
Compare
blktests-ci
bot
force-pushed
the
linus-master_base
branch
from
00d5e5c to
d782508
Compare
Author
|
Upstream branch: f824272 |
blktests-ci
bot
force-pushed
the
series/1023830=>linus-master
branch
from
6fca0f5 to
3c6d4db
Compare
blktests-ci
bot
force-pushed
the
linus-master_base
branch
from
d782508 to
6099a4d
Compare
Author
|
Upstream branch: e7c375b |
blktests-ci
bot
force-pushed
the
series/1023830=>linus-master
branch
from
3c6d4db to
c76ab0e
Compare
blktests-ci
bot
force-pushed
the
linus-master_base
branch
from
6099a4d to
5121c4d
Compare
Author
|
Upstream branch: e7c375b |
blktests-ci
bot
force-pushed
the
series/1023830=>linus-master
branch
from
c76ab0e to
99d3cc4
Compare
blktests-ci
bot
force-pushed
the
linus-master_base
branch
from
5121c4d to
4458758
Compare
Author
|
Upstream branch: 8b69055 |
blktests-ci
bot
force-pushed
the
series/1023830=>linus-master
branch
from
99d3cc4 to
bf56958
Compare
blktests-ci
bot
force-pushed
the
linus-master_base
branch
from
4458758 to
6f43942
Compare
The write pointer of zones that are in the full condition is always invalid. Reflect that fact by setting the write pointer of full zones to ULLONG_MAX. Fixes: eb0570c ("block: new zoned loop block device driver") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]>
zloop_rw() will fail any regular write operation that targets a full sequential zone. The check for this is indirect and achieved by checking the write pointer alignment of the write operation. But this check is ineffective for zone append operations since these are alwasy automatically directed at a zone write pointer. Prevent zone append operations from being executed in a full zone with an explicit check of the zone condition. Fixes: eb0570c ("block: new zoned loop block device driver") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]>
The function zloop_rw() already checks early that a request is fully contained within the target zone. So this check does not need to be done again for regular writes to sequential zones. Furthermore, since zone append operations are always directed to the zone write pointer location, we do not need to check for their alignment to that value after setting it. So turn the "if" checking the write pointer alignment into an "else if". While at it, improve the comment describing the write pointer modification and how this value is corrected in case of error. Signed-off-by: Damien Le Moal <[email protected]>
A zloop zoned block device declares to the block layer that it supports zone append operations. That is, a zloop device ressembles an NVMe ZNS devices supporting zone append. This native support is fine but it does not allow exercising the block layer zone write plugging emulation of zone append, as is done with SCSI or ATA SMR HDDs. Introduce the zone_append configuration parameter to allow creating a zloop device without native support for zone append, thus relying on the block layer zone append emulation. If not specified, zone append support is enabled by default. Otherwise, a value of 0 disables native zone append and a value of 1 enables it. Signed-off-by: Damien Le Moal <[email protected]>
The zone append operation processing for zloop devices is similar to any other command, that is, the operation is processed as a command work item, without any special serialization between the work items (beside the zone mutex for mutually exclusive code sections). This processing is fine and gives excellent performance. However, it has a side effect: zone append operation are very often reordered and processed in a sequence that is very different from their issuing order by the user. This effect is very visible using an XFS file system on top of a zloop device. A simple file write leads to many file extents as the data writes using zone append are reordered and so result in the physical order being different than the file logical order. E.g. executing: $ dd if=/dev/zero of=/mnt/test bs=1M count=10 && sync $ xfs_bmap /mnt/test /mnt/test: 0: [0..4095]: 2162688..2166783 1: [4096..6143]: 2168832..2170879 2: [6144..8191]: 2166784..2168831 3: [8192..10239]: 2170880..2172927 4: [10240..12287]: 2174976..2177023 5: [12288..14335]: 2172928..2174975 6: [14336..20479]: 2177024..2183167 For 10 IOs, 6 extents are created. This is fine and actually allows to exercise XFS zone garbage collection very well. However, this also makes debugging/working on XFS data placement harder as the underlying device will most of the time reorder IOs, resulting in many file extents. Allow a user to mitigate this with the new ordered_zone_append configuration parameter. For a zloop device created with this parameter specified, the sector of a zone append command is set early, when the command is submitted by the block layer with the zloop_queue_rq() function, instead of in the zloop_rw() function which is exectued later in the command work item context. This change ensures that more often than not, zone append operations data end up being written in the same order as the command submission by the user. In the case of XFS, this leads to far less file data extents. E.g., for the previous example, we get a single file data extent for the written file. $ dd if=/dev/zero of=/mnt/test bs=1M count=10 && sync $ xfs_bmap /mnt/test /mnt/test: 0: [0..20479]: 2162688..2183167 Since we cannot use a mutex in the context of the zloop_queue_rq() function to atomically set a zone append operation sector to the target zone write pointer location and increment that the write pointer, a new per-zone spinlock is introduced to protect a zone write pointer access and modifications. To check a zone write pointer location and set a zone append operation target sector to that value, the function zloop_set_zone_append_sector() is introduced and called from zloop_queue_rq(). Signed-off-by: Damien Le Moal <[email protected]>
Author
|
Upstream branch: fd95357 |
In Documentation/admin-guide/blockdev/zoned_loop.rst, add the description of the zone_append and ordered_zone_append configuration arguments of zloop "add" command (device creation). Signed-off-by: Damien Le Moal <[email protected]>
blktests-ci
bot
force-pushed
the
series/1023830=>linus-master
branch
from
bf56958 to
a03d1ab
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull request for series with
subject: zloop fixes and improvements
version: 1
url: https://patchwork.kernel.org/project/linux-block/list/?series=1023830