On Tue, Sep 20, 2022 at 12:49 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Thu, Sep 15, 2022 at 09:48:22AM -0700, Sarthak Kukreti wrote: > > From: Sarthak Kukreti <sarthakkukreti@xxxxxxxxxxxx> > > > > FALLOC_FL_PROVISION is a new fallocate() allocation mode that > > sends a hint to (supported) thinly provisioned block devices to > > allocate space for the given range of sectors via REQ_OP_PROVISION. > > So, how does that "provisioning" actually work in todays world where > storage is usually doing out of place writes in one or more layers, > including the flash storage everyone is using. Does it give you one > write? And unlimited number? Some undecided number inbetween? Apologies, the patchset was a bit short on describing the semantics so I'll expand more in the next revision; I'd say that it's the minimum of regular mode fallocate() guarantees at each allocation layer. For example, the guarantees from a contrived storage stack like (left to right is bottom to top): [ mmc0blkp1 | ext4(1) | sparse file | loop | dm-thinp | dm-thin | ext4(2) ] would be predicated on the guarantees of fallocate() per allocation layer; if ext4(1) was replaced by a filesystem that did not support fallocate(), then there would be no guarantee that a write to a file on ext4(2) succeeds. For dm-thinp, in the current implementation, the provision request allocates blocks for the range specified and adds the mapping to the thinpool metadata. All subsequent writes are to the same block, so you'll be able to write to the same block inifinitely. Brian mentioned this above, one case it doesn't cover is if provision is called on a shared block, but the natural extension would be to allocate and assign a new block and copy the contents of the shared block (kind of like copy-on-provision). [reflowed] > How is it affected by write zeroes to that range or a discard? The current semantics of discards for dm-thinp/ext4/sparse files will apply as they do today; discards will unmap the dm-thin block/free the file extent. Write zeroes is more interesting; dm-thinp will treat the command as usual. ext4_zero_range will mark the extents as unwritten, so essentially if a user did provision + write to a block, write zeros to the block would essentially leave it in the original provisioned state, but ext4 would now show the contents of the block as zero on the next read. I think, similar to above, the semantics of a request will depend on each layer that it passes through. Best Sarthak -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
