On Fri, Oct 06, 2023 at 06:28:15PM -0700, Sarthak Kukreti wrote: > Add support for provision requests to loopback devices. > Loop devices will configure provision support based on > whether the underlying block device/file can support > the provision request and upon receiving a provision bio, > will map it to the backing device/storage. For loop devices > over files, a REQ_OP_PROVISION request will translate to > an fallocate mode 0 call on the backing file. > > Signed-off-by: Sarthak Kukreti <sarthakkukreti@xxxxxxxxxxxx> > Signed-off-by: Mike Snitzer <snitzer@xxxxxxxxxx> Hmmmm. This doesn't actually implement the required semantics of REQ_PROVISION. Yes, it passes the command to the filesystem fallocate() implementation, but fallocate() at the filesystem level does not have the same semantics as REQ_PROVISION. i.e. at the filesystem level, fallocate() only guarantees the next write to the provisioned range will succeed without ENOSPC, it does not guarantee *every* write to the range will succeed without ENOSPC. If someone clones the loop file while it is in use (i.e. snapshots it via cp --reflink) then all guarantees that the next write to a provisioned LBA range will succeed without ENOSPC are voided. So while this will work for basic testing that the filesystem is issuing REQ_PROVISION based IO correctly, it can't actually be used for hosting production filesystems that need full REQ_PROVISION guarantees when the loop device backing file is independently shapshotted via FICLONE.... At minimuim, this set of implementation constraints needs tobe documented somewhere... -Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
