Hi all,
this series adds support for zoned devices:
https://zonedstorage.io/docs/introduction/zoned-storage
to XFS. It has been developed for and tested on both SMR hard drives,
which are the oldest and most common class of zoned devices:
https://zonedstorage.io/docs/introduction/smr
and ZNS SSDs:
https://zonedstorage.io/docs/introduction/zns
It has not been tested with zoned UFS devices, as their current capacity
points and performance characteristics aren't too interesting for XFS
use cases (but never say never).
Sequential write only zones are only supported for data using a new
allocator for the RT device, which maps each zone to a rtgroup which
is written sequentially. All metadata and (for now) the log require
using randomly writable space. This means a realtime device is required
to support zoned storage, but for the common case of SMR hard drives
that contain random writable zones and sequential write required zones
on the same block device, the concept of an internal RT device is added
which means using XFS on a SMR HDD is as simple as:
$ mkfs.xfs /dev/sda
$ mount /dev/sda /mnt
When using NVMe ZNS SSDs that do not support conventional zones, the
traditional multi-device RT configuration is required. E.g. for an
SSD with a conventional namespace 1 and a zoned namespace 2:
$ mkfs.xfs /dev/nvme0n1 -o rtdev=/dev/nvme0n2
$ mount -o rtdev=/dev/nvme0n2 /dev/nvme0n1 /mnt
The zoned allocator can also be used on conventional block devices, or
on conventional zones (e.g. when using an SMR HDD as the external RT
device). For example using zoned XFS on normal SSDs shows very nice
performance advantages and write amplification reduction for intelligent
workloads like RocksDB.
This series depends on Darrick's rtrmap work to support garbage
collection, and on the rtreflink series for a stable baseline despite
not having support for reflinks yet to avoid having to cherry pick
individual patches for it.
As pointed out in the subject this is an RFC, formal submission can't
be done until the dependencies have landed, but the overall structure
and disk format is ready for review and we'd love to hear your feedback.
Some work is still in progress or planned, but should not affect the
integration with the rest of XFS or the on-disk format:
- support for quotas
- support for reflinks - the I/O path already supports them, but
garbage collection currently isn't refcount aware and would unshare
them, rendering the feature useless
- more scalable garbage collection victim selection
- various improvements to hint based data placement
And probably a lot more after we're getting review feedback.
To make testing easier a git tree is provided that has the XFS
dependencies, the iomap series and this code:
git://git.infradead.org/users/hch/xfs.git xfs-zoned
The matching xfsprogs is available here:
git://git.infradead.org/users/hch/xfsprogs.git xfs-zoned
An xfstests branch to enable the zoned code, and with various new tests
is here:
git://git.infradead.org/users/hch/xfstests-dev.git xfs-zoned
An updated xfs-documentation branch documenting the on-disk format is
here:
git://git.infradead.org/users/hch/xfs-documentation.git xfs-zoned
Gitweb:
http://git.infradead.org/users/hch/xfs.git/shortlog/refs/heads/xfs-zoned
http://git.infradead.org/users/hch/xfsprogs.git/shortlog/refs/heads/xfs-zoned
http://git.infradead.org/users/hch/xfstests-dev.git/shortlog/refs/heads/xfs-zoned
http://git.infradead.org/users/hch/xfs-documentation.git/shortlog/refs/heads/xfs-zoned
