Skip to content

File Systems and Zoned Block Devices

The dm-zoned device mapper target allows using any file system with host managed zoned block devices by hiding the device sequential write constraints. This is a simple solution to enable a file system use but not necessarily the most efficient due to the potentially high overhead of a block based zone reclaim process.

Supporting zoned block devices directly in a file system implementation can lead to a more efficient zone reclaim processing as the file system metadata and file abstraction provide more information on the usage and validity status of storage blocks compared to the raw block device based approach.

Furthermore, a file system design may lend itself well to the sequential write constraint of host managed zoned block devices. This is the case for log-structured file systems such as F2FS and copy-on-write (CoW) file systems such as Btrfs.

F2FS

The Flash-Friendly File System (F2FS) was designed on a basis of a log-structured file system approach but modified to avoid the classical problems of the traditional log-structured approach (e.g. The snowball effect of wandering trees and the high cleaning overhead).

F2FS supports various parameters not only for configuring on-disk layout but also for selecting allocation and cleaning algorithms.

Zoned Block Device Support

Zoned block device support was added to F2FS with kernel 4.10. Since F2FS uses a metadata block on-disk format with fixed block location, only zoned block devices which include conventional zones can be supported. Zoned devices composed entirely of sequential zones cannot be used with F2FS as a standalone device and require a multi-device setup to place metadata blocks on a randomly writable storage. F2FS supports multi-device setup where multiple block device address spaces are linearly concatenated to form a logically larger block device. The dm-linear device mapper target can also be used to create a logical device composed of conventional zones and sequential zones suitable for F2FS.

F2FS zoned block device support was achieved using the following principles.

  1. Section Alignment In F2FS, a section is a group of fixed size segments (2 MB). The number of segments in a section is determined to match the zoned device zone size. For instance, with a 256 MB zone size, a section contains 128 segments of 2MB.
  2. Forced LFS mode By default, F2FS tries to optimize block allocation to avoid excessive append write by allowing some random writes within segments. The LFS mode forces sequential writes to segments and the sequential use of segments within sections, resulting in full compliance with zoned block devices write constraint.
  3. Zone reset as discard operation Block discard (or trim) used to indicate to a device that a block or range of blocks are no longer in use is replaced with execution of a zone write pointer reset command when all blocks of all segments of a section are free, allowing the section to be reused.

Limitations

F2FS uses 32 bits block number with a block size of 4 KB. This results in a maximum volume size of 16 TB. Any device with a total capacity larger than 16 TB cannot be used with F2FS.

To overcome this limit, the dm-linear device mapper target can be used to partition a zoned block device into serviceable smaller logical devices. This configuration must ensure that each logical device created is assigned a sufficient amount of conventional zones to store F2FS fixed location metadata blocks.

Usage Example

To format a zoned block device with mkfs.f2fs, the option -m must be specified.

# mkfs.f2fs -m /dev/sdb

    F2FS-tools: mkfs.f2fs Ver: 1.12.0 (2018-11-12)

Info: Disable heap-based policy
Info: Debug level = 0
Info: Trim is enabled
Info: [/dev/sdb] Disk Model: HGST HSH721415AL
Info: Host-managed zoned block device:
      55880 zones, 524 randomly writeable zones
      65536 blocks per zone
Info: Segments per section = 128
Info: Sections per zone = 1
Info: sector size = 4096
Info: total sectors = 3662151680 (14305280 MB)
Info: zone aligned segment0 blkaddr: 65536
Info: format version with
  "Linux version 5.0.16-300.fc30.x86_64 (mockbuild@bkernel03.phx2.fedoraproject.org) (gcc version 9.1.1 20190503 (Red Hat 9.1.1-1) (GCC)) #1 SMP Tue May 14 19:33:09 UTC 2019"
Info: [/dev/sdb] Discarding device
Info: Discarded 14305280 MB
Info: Overprovision ratio = 0.600%
Info: Overprovision segments = 86254 (GC reserved = 43690)
Info: format successful

The formatted zoned block device can now be directly mounted without any other setup necessary.

# mount /dev/sdb /mnt

Compared to the dm-zoned device mapper target solution, performance of F2FS does not suffer from zone reclaim overhead as writes are always sequential and do not require on-disk temporary buffering. F2FS garbage collection (segment cleanup) will generate performance overhead only for workloads frequently deleting file or modifying files data.

Btrfs

Btrfs is a file system based on the copy-on-write (CoW) principle resulting in any block update to never be written in-place. Work is ongoing to add native ZBD support by changing the block allocation algorithm and block IO issuing code.

Block Allocation Changes

Btrfs block management relies on grouping of blocks into block groups, with each group composed of one or more device extent. The device extents of a block group may belong to different devices (e.g. In the case of a RAID volume). ZBD support changes the default device extent size to the size of the device zones so that all device extents are always aligned to a zone.

Allocation of blocks within a block group is changed so that the allocation is always sequential from the beginning of the block group. To do so, an allocation pointer is added to block groups and used as the allocation hint. The changes also ensure that block freed below the allocation pointer are ignored, resulting in sequential block allocation within each group regardless of the block group usage.

I/O Management

While the introduction of the allocation pointer ensures that blocks are allocated sequentially within groups, so sequentially within zones, I/Os to write out newly allocated blocks may be issued out of order causing errors when writing to sequential zones. This problem is solved by introducing a write I/O request staging list to each block group. This list is used to delay the execution of unaligned write requests within a block group.

The zones of a block group are reset to allow rewriting only when the block group is being freed, that is, when all the blocks within the block group are unused.

For Btrfs volumes composed of multiple disks, restrictions are added to ensure that all disks have the same zone model and in the case of zoned block devices, the same zone size. This matches the existing Btrfs constraint that all device extents in a block group must have the same size.

Upstream Contribution

Btrfs zoned block device support is still in development and will be available in stable releases after the usual upstream review process completes.

XFS

XFS currently does not support zoned block devices. The dm-zoned device mapper target must be used to enable zoned device use with XFS.

An early design document discussed the development work necessary to support host aware and host managed disks with XFS. Parts of this design have already been implemented and included into the kernel stable releases (e.g. Per inode reverse block mapping b-trees feature). However, more work is necessary to fully support zoned block devices.

ext4

This article describes attempts at improving ext4 performance with host aware zoned block devices using changes to the file system journal management. The changes are small and succeed in maintaining good performance. However, support for host managed zoned block devices is not provided as some fundamental ext4 design aspects cannot be easily changed to match host managed device constraints.

These optimizations for host aware zoned block devices is a research work and is not included in ext4 stable kernel releases. ext4 also does not support host managed disks. Similarly to XFS, the ext4 file system can however be used together with the dm-zoned device mapper target.