diff options
author | Damien Le Moal <damien.lemoal@wdc.com> | 2017-06-07 15:55:39 +0900 |
---|---|---|
committer | Mike Snitzer <snitzer@redhat.com> | 2017-06-19 11:05:20 -0400 |
commit | 3b1a94c88b798d4f3bd1a5b61f5c8fb9d987c242 (patch) | |
tree | 173fcaced4dffd3e7d334a2992e40a9466747b91 /drivers/md/Kconfig | |
parent | b73c67c2cbb0004e6da9720a167fe42e31f7a6e8 (diff) | |
download | linux-stable-3b1a94c88b798d4f3bd1a5b61f5c8fb9d987c242.tar.gz linux-stable-3b1a94c88b798d4f3bd1a5b61f5c8fb9d987c242.tar.bz2 linux-stable-3b1a94c88b798d4f3bd1a5b61f5c8fb9d987c242.zip |
dm zoned: drive-managed zoned block device target
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 <damien.lemoal@wdc.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
[Mike Snitzer partly refactored Damien's original work to cleanup the code]
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Diffstat (limited to 'drivers/md/Kconfig')
-rw-r--r-- | drivers/md/Kconfig | 17 |
1 files changed, 17 insertions, 0 deletions
diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig index 906103c168ea..4a249ee86364 100644 --- a/drivers/md/Kconfig +++ b/drivers/md/Kconfig @@ -521,6 +521,23 @@ config DM_INTEGRITY To compile this code as a module, choose M here: the module will be called dm-integrity. +config DM_ZONED + tristate "Drive-managed zoned block device target support" + depends on BLK_DEV_DM + depends on BLK_DEV_ZONED + ---help--- + This device-mapper target takes a host-managed or host-aware zoned + block device and exposes most of its capacity as a regular block + device (drive-managed zoned block device) without any write + constraints. This is mainly intended for use with file systems that + do not natively support zoned block devices but still want to + benefit from the increased capacity offered by SMR disks. Other uses + by applications using raw block devices (for example object stores) + are also possible. + + To compile this code as a module, choose M here: the module will + be called dm-zoned. + If unsure, say N. endif # MD |