On Mon, Feb 17, 2014 at 08:31:50PM -0500, Martin K. Petersen wrote: > > Your variant seems to land somewhere in-between. You want a > blkdev_issue_clear() that zeroes a block range and it's then up to the > storage device to decide whether to provision or deprovision the space > as long as you are guaranteed to get zeroes back for each block in the > range on a subsequent read. Is that a correct interpretation? Ultimately the storage device (or host OS) can always decide to deprovision the space if it is given a write of all zeroes; there's nothing in the specs that say anything at all about performance considerations, or what the back-end storage decides to do in order to handle a particular write command, so long as a subsequent read returns the correct data. So what I want is a way in which the guest (kernel, file system, etc) should be able to request that the space be deprovisioned. So it's a hint insofar ultimately, the host can always decide whether or not whether or not to honor the deprovision request (or the host could decide to deprovision a block even if it's not explicitly requested). However, I don't want it to be a hint insofar that a subsequent read is *guaranteed* to return all zeros after this "blkdev_issue_clear()" command has been successfully sent to the device. Does that make sense? > I'm trying to pin down your exact use case because it can get very murky > between the SCSI and ATA variants. And the fact that the same knobs are > used for both over and under-provisioned devices. SCSI also has an > additional state: Blocks can be either mapped, anchored or deallocated. What does "anchored" mean? Does is it the equivalent of using fallocate() to allocate the block, but it's marked uninitialized so any attempt to read it returns zeroes? If so, that certainly sounds like useful functionality that would be great if KVM exposed via virt-scsi. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
