Re: support for zoned devices v4

[Damien Le Moal <dlemoal@kernel.org>]

On 2/27/25 03:56, Christoph Hellwig wrote:
> 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.
> 
> 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
> 
> To make testing easier a git tree is provided that has the required
> iomap changes that we merged through the VFS tree, this code and a
> few misc patches that make VM testing easier:
> 
>     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

I ran this several times doing short runs and a long run over the weekend on a
30TB SMR HDD, doing random sized buffered writes, read and readwrite IOs to
randomly sized files.

Working great for me. So:

Tested-by: Damien Le Moal <dlemoal@kernel.org>

-- 
Damien Le Moal
Western Digital Research