06 Jun, 2020
7 commits
-
per-device reclaim should select zones on that device only.
Signed-off-by: Hannes Reinecke
Reviewed-by: Damien Le Moal
Signed-off-by: Mike Snitzer -
When allocating a zone, pass in an indicator on which device the zone
should be allocated; this increases performance for a multi-device
setup because reclaim will now allocate zones on the device for which
reclaim is running.Signed-off-by: Hannes Reinecke
Reviewed-by: Damien Le Moal
Signed-off-by: Mike Snitzer -
Random and sequential zones should be part of the respective
device structure to make arbitration between devices possible.Signed-off-by: Hannes Reinecke
Reviewed-by: Damien Le Moal
Signed-off-by: Mike Snitzer -
Instead of having one reclaim workqueue for the entire set we should
be allocating a reclaim workqueue per device; doing so will reduce
contention and should boost performance for a multi-device setup.Signed-off-by: Hannes Reinecke
Reviewed-by: Damien Le Moal
Signed-off-by: Mike Snitzer -
Add a metadata pointer within struct dmz_dev and use it as argument
for blkdev_report_zones() instead of the metadata itself.Signed-off-by: Hannes Reinecke
Reviewed-by: Damien Le Moal
Signed-off-by: Mike Snitzer -
Add a pointer, to the containing device, within struct dm_zone and
kill dmz_zone_to_dev().Signed-off-by: Hannes Reinecke
Reviewed-by: Damien Le Moal
Signed-off-by: Mike Snitzer -
Instead of counting the number of reserved zones in dmz_free_zone(),
mark the zone as 'reserved' during allocation and simplify
dmz_free_zone().Signed-off-by: Hannes Reinecke
Reviewed-by: Damien Le Moal
Signed-off-by: Mike Snitzer
21 May, 2020
4 commits
-
When dmz_get_chunk_mapping() selects a zone which is under reclaim
we should terminate the reclaim copy process. Since we're changing
the zone itself, reclaim needs to run afterwards again anyway.Signed-off-by: Hannes Reinecke
Reviewed-by: Damien Le Moal
Signed-off-by: Mike Snitzer -
When the system is idle we should be starting reclaiming
random zones, too.Signed-off-by: Hannes Reinecke
Reviewed-by: Damien Le Moal
Signed-off-by: Mike Snitzer -
Instead of lumping emulated zones together with random zones we
should be handling them as separate 'cache' zones. This improves
code readability and allows an easier implementation of different
cache policies.Also add additional allocation flags, to separate the type (cache,
random, or sequential) from the purpose (eg reclaim).Also switch the allocation policy to not use random zones as buffer
zones if cache zones are present. This avoids a performance drop when
all cache zones are used.Signed-off-by: Hannes Reinecke
Reviewed-by: Damien Le Moal
Signed-off-by: Mike Snitzer -
Implement handling for metadata version 2. The new metadata adds a
label and UUID for the device mapper device, and additional UUID for
the underlying block devices.It also allows for an additional regular drive to be used for
emulating random access zones. The emulated zones will be placed
logically in front of the zones from the zoned block device, causing
the superblocks and metadata to be stored on that device.The first zone of the original zoned device will be used to hold
another, tertiary copy of the metadata; this copy carries a generation
number of 0 and is never updated; it's just used for identification.Signed-off-by: Hannes Reinecke
Reviewed-by: Bob Liu
Reviewed-by: Damien Le Moal
Signed-off-by: Mike Snitzer
20 May, 2020
1 commit
-
Use the dmz_zone_to_dev() mapping function to remove the
'dev' argument from reclaim.Signed-off-by: Hannes Reinecke
Reviewed-by: Bob Liu
Reviewed-by: Damien Le Moal
Signed-off-by: Mike Snitzer
15 May, 2020
5 commits
-
Introduce accessors dmz_dev_is_dying() and dmz_check_dev() to
avoid having to reference the devices directly.Signed-off-by: Hannes Reinecke
Reviewed-by: Bob Liu
Reviewed-by: Damien Le Moal
Signed-off-by: Mike Snitzer -
Introduce dmz_metadata_label() to format the device-mapper device
name and use it instead of the device name of the underlying device.Signed-off-by: Hannes Reinecke
Reviewed-by: Damien Le Moal
Reviewed-by: Bob Liu
Signed-off-by: Mike Snitzer -
Move fields from the device structure into the metadata structure
and provide accessor functions.Signed-off-by: Hannes Reinecke
Reviewed-by: Damien Le Moal
Reviewed-by: Bob Liu
Signed-off-by: Mike Snitzer -
Instead of calculating the zone index by the offset within the
zone array store the index within the structure itself. With that
the helper dmz_id() is pointless and can be replaced with accessing
the ->id value directly.Signed-off-by: Hannes Reinecke
Reviewed-by: Bob Liu
Reviewed-by: Damien Le Moal
Signed-off-by: Mike Snitzer -
Add callback to supply information for 'dmsetup status'
and 'dmsetup table'. The output for 'dmsetup status' is0 zoned zones / random / sequential
where is the number of unmapped (ie free) random zones,
the total number of random zones, the number
of unmapped sequential zones, and the total number of
sequential zones.Signed-off-by: Hannes Reinecke
Reviewed-by: Bob Liu
Reviewed-by: Damien Le Moal
Signed-off-by: Mike Snitzer
07 Nov, 2019
1 commit
-
Commit 75d66ffb48efb3 added backing device health checks and as a part
of these checks, check_events() block ops template call is invoked in
dm-zoned mapping path as well as in reclaim and flush path. Calling
check_events() with ATA or SCSI backing devices introduces a blocking
scsi_test_unit_ready() call being made in sd_check_events(). Even though
the overhead of calling scsi_test_unit_ready() is small for ATA zoned
devices, it is much larger for SCSI and it affects performance in a very
negative way.Fix this performance regression by executing check_events() only in case
of any I/O errors. The function dmz_bdev_is_dying() is modified to call
only blk_queue_dying(), while calls to check_events() are made in a new
helper function, dmz_check_bdev().Reported-by: zhangxiaoxu
Fixes: 75d66ffb48efb3 ("dm zoned: properly handle backing device failure")
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Fomichev
Signed-off-by: Mike Snitzer
16 Aug, 2019
2 commits
-
Signed-off-by: Dmitry Fomichev
Reviewed-by: Damien Le Moal
Signed-off-by: Mike Snitzer -
dm-zoned is observed to lock up or livelock in case of hardware
failure or some misconfiguration of the backing zoned device.This patch adds a new dm-zoned target function that checks the status of
the backing device. If the request queue of the backing device is found
to be in dying state or the SCSI backing device enters offline state,
the health check code sets a dm-zoned target flag prompting all further
incoming I/O to be rejected. In order to detect backing device failures
timely, this new function is called in the request mapping path, at the
beginning of every reclaim run and before performing any metadata I/O.The proper way out of this situation is to do
dmsetup remove
and recreate the target when the problem with the backing device
is resolved.Fixes: 3b1a94c88b79 ("dm zoned: drive-managed zoned block device target")
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Fomichev
Reviewed-by: Damien Le Moal
Signed-off-by: Mike Snitzer
17 Jul, 2019
1 commit
-
dm-zoned uses the zone flag DMZ_ACTIVE to indicate that a zone of the
backend device is being actively read or written and so cannot be
reclaimed. This flag is set as long as the zone atomic reference
counter is not 0. When this atomic is decremented and reaches 0 (e.g.
on BIO completion), the active flag is cleared and set again whenever
the zone is reused and BIO issued with the atomic counter incremented.
These 2 operations (atomic inc/dec and flag set/clear) are however not
always executed atomically under the target metadata mutex lock and
this causes the warning:WARN_ON(!test_bit(DMZ_ACTIVE, &zone->flags));
in dmz_deactivate_zone() to be displayed. This problem is regularly
triggered with xfstests generic/209, generic/300, generic/451 and
xfs/077 with XFS being used as the file system on the dm-zoned target
device. Similarly, xfstests ext4/303, ext4/304, generic/209 and
generic/300 trigger the warning with ext4 use.This problem can be easily fixed by simply removing the DMZ_ACTIVE flag
and managing the "ACTIVE" state by directly looking at the reference
counter value. To do so, the functions dmz_activate_zone() and
dmz_deactivate_zone() are changed to inline functions respectively
calling atomic_inc() and atomic_dec(), while the dmz_is_active() macro
is changed to an inline function calling atomic_read().Fixes: 3b1a94c88b79 ("dm zoned: drive-managed zoned block device target")
Cc: stable@vger.kernel.org
Reported-by: Masato Suzuki
Signed-off-by: Damien Le Moal
Signed-off-by: Mike Snitzer
19 Jun, 2017
1 commit
-
The dm-zoned device mapper target provides transparent write access
to zoned block devices (ZBC and ZAC compliant block devices).
dm-zoned hides to the device user (a file system or an application
doing raw block device accesses) any constraint imposed on write
requests by the device, equivalent to a drive-managed zoned block
device model.Write requests are processed using a combination of on-disk buffering
using the device conventional zones and direct in-place processing for
requests aligned to a zone sequential write pointer position.
A background reclaim process implemented using dm_kcopyd_copy ensures
that conventional zones are always available for executing unaligned
write requests. The reclaim process overhead is minimized by managing
buffer zones in a least-recently-written order and first targeting the
oldest buffer zones. Doing so, blocks under regular write access (such
as metadata blocks of a file system) remain stored in conventional
zones, resulting in no apparent overhead.dm-zoned implementation focus on simplicity and on minimizing overhead
(CPU, memory and storage overhead). For a 14TB host-managed disk with
256 MB zones, dm-zoned memory usage per disk instance is at most about
3 MB and as little as 5 zones will be used internally for storing metadata
and performing buffer zone reclaim operations. This is achieved using
zone level indirection rather than a full block indirection system for
managing block movement between zones.dm-zoned primary target is host-managed zoned block devices but it can
also be used with host-aware device models to mitigate potential
device-side performance degradation due to excessive random writing.Zoned block devices can be formatted and checked for use with the dm-zoned
target using the dmzadm utility available at:https://github.com/hgst/dm-zoned-tools
Signed-off-by: Damien Le Moal
Reviewed-by: Hannes Reinecke
Reviewed-by: Bart Van Assche
[Mike Snitzer partly refactored Damien's original work to cleanup the code]
Signed-off-by: Mike Snitzer