Linux 6.5 Slated To Add Provisioning Primitives For Thinly Provisioned Storage
A branch created over the weekend was linux-dm.git's dm-6.5-provision-support. With it now on a branch marked for "6.5", appears positioned to be sent in for the upcoming Linux 6.5 merge window barring any issues from being raised by Linus Torvalds or other kernel developers.
These provisioning primitives were worked on by Google's Chrome OS team. Sarthak Kukreti of Google previously explained of this initiative in the earlier RFC patches on the mailing list:
"This patch series is an RFC of a mechanism to pass through provision requests on stacked thinly provisioned storage devices/filesystems.
The linux kernel provides several mechanisms to set up thinly provisioned block storage abstractions (eg. dm-thin, loop devices over sparse files), either directly as block devices or backing storage for filesystems. Currently, short of writing data to either the device or filesystem, there is no way for users to pre-allocate space for use in such storage setups. Consider the following use-cases:
1) Suspend-to-disk and resume from a dm-thin device: In order to ensure that the underlying thinpool metadata is not modified during the suspend mechanism, the dm-thin device needs to be fully provisioned.
2) If a filesystem uses a loop device over a sparse file, fallocate() on the filesystem will allocate blocks for files but the underlying sparse file will remain intact.
3) Another example is virtual machine using a sparse file/dm-thin as a storage device; by default, allocations within the VM boundaries will not affect the host.
4) Several storage standards support mechanisms for thin provisioning on real hardware devices. For example:
a. The NVMe spec 1.0b section 2.1.1 loosely talks about thin provisioning: "When the THINP bit in the NSFEAT field of the Identify Namespace data structure is set to ‘1’, the controller ... shall track the number of allocated blocks in the Namespace Utilization field"
b. The SCSi Block Commands reference - 4 section references "Thin provisioned logical units",
c. UFS 3.0 spec section 13.3.3 references "Thin provisioning".
In all of the above situations, currently the only way for pre-allocating space is to issue writes (or use WRITE_ZEROES/WRITE_SAME). However, that does not scale well with larger pre-allocation sizes.
This patchset introduces primitives to support block-level provisioning (note: the term 'provisioning' is used to prevent overloading the term 'allocations/pre-allocations') requests across filesystems and block devices. This allows fallocate() and file creation requests to reserve space across stacked layers of block devices and filesystems. Currently, the patchset covers a prototype on the device-mapper targets, loop device and ext4, but the same mechanism can be extended to other filesystems/block devices as well as extended for use with devices in 4 a-c."
The patch introducing the REQ_OP_PROVISION request simply sums up this provisioning as:
"Introduce block request REQ_OP_PROVISION. The intent of this request is to request underlying storage to preallocate disk space for the given block range. Block devices that support this capability will export a provision limit within their request queues.
This patch also adds the capability to call fallocate() in mode 0 on block devices, which will send REQ_OP_PROVISION to the block device for the specified range,"
This block provisioning primitives work has been in the works for several months and successfully tested on Chrome OS and against the upstream Linux kernel. The block and DM changes around REQ_OP_PROVISION as well as the loopback device support for it is now poised to appear in Linux 6.5.
The Linux 6.5 merge window is expected to begin next week if the Linux 6.4 stable release isn't pushed back by an extra week. Linux 6.5 stable in turn should debut around the end of August.
2 Comments
