On Tue, Oct 10, 2023 at 03:42:53PM -0700, Sarthak Kukreti wrote: > On Sun, Oct 8, 2023 at 4:50 PM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > > On Fri, Oct 06, 2023 at 06:28:12PM -0700, Sarthak Kukreti wrote: > > > Hi, > > > > > > This patch series is version 8 of the patch series to introduce > > > block-level provisioning mechanism (original [1]), which is useful for provisioning > > > space across thinly provisioned storage architectures (loop devices > > > backed by sparse files, dm-thin devices, virtio-blk). This series has > > > minimal changes over v7[2]. > > > > > > This patch series is rebased from the linux-dm/dm-6.5-provision-support [1] on to > > > (cac405a3bfa2 Merge tag 'for-6.6-rc3-tag'). In addition, there's an > > > additional patch to allow passing through an unshare intent via REQ_OP_PROVISION > > > (suggested by Darrick in [4]). > > > > The XFS patches I just posted were smoke tested a while back against > > loop devices and then forward ported to this patchset. Good for > > testing that userspace driven file preallocation gets propagated by > > the filesystem down to the backing device correctly and that > > subsequent IO to the file then does the right thing (e.g. fio > > testing using fallocate() to set up the files being written to).... > > > > Thanks! I've been testing with a WIP patch for ext4, I'll give your > patches a try. Once we are closer to submitting the filesystem > support, we can formalize the test into an xfstest (sparse file + loop > + filesystem, fallocate() file, check the size of the underlying > sparse file). That's not really a valid test - there are so many optional filesystem behaviours that can change the layout of the backing file for the same upper filesystem operations. What we actually need to test is the ENOSPC guarantees, not that fallocate has been called by the loop device. i.e. that ENOSPC is propagated from the underlying filesystem though the loop device to the application running on the upper filesystem appropriately. e.g. when the lower filesystem is at ENOSPC, the writes into provisioned space in the loop device backing file continue to succeed without ENOSPC being reported to the upper filesystem. i.e. this needs to be tested from the perspective of the API presented to the upper filesystem, not by running an upper fs operation and then trying to infer correct behaviour by peering at the state of the lower filesystem... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
