On Thu, Aug 17, 2017 at 09:47:44AM +0200, Lukas Czerner wrote: > There are many users that historically benefit from the > "discard_zeroes_data" semantics. For example mkfs, where it's beneficial > to discard the blocks before creating a file system and if we also get > deterministic zeroes on read, even better since we do not have to > initialize some portions of the file system manually. But that's now what discard_zeroes_data gives you unfortunately. > So I understand now that Deterministic Read Zero after TRIM is not > realiable so we do not want to use that flag because we can't guarantee > it in this case. However there are other situations where we can such > as loop device (might be especially usefull for VM) where backing file > system supports punch hole, or even SCSI write same with UNMAP ? > > Currently user space can call fallocate with FALLOC_FL_PUNCH_HOLE | > FALLOC_FL_KEEP_SIZE however if that succeeds we're only guaranteed that > the range has been zeroed, not unmapped/discarded ? (that's not very > clear from the comments). None of the modes seems to guarantee both > zeroout and unmap in case of success. However still, there seem to be no > way to tell what's actually supported from user space without ending up > calling fallocate, is there ? While before we had discard_zeroes_data > which people learned to rely on in certain situations, even though it > might have been shaky. You never get (and never got) a guarantee that the blocks were unmapped as none of the storage protocol ever requires the device to deallocate. Because devices have their internal chunk/block size everything else would be impractival. But fallocate FALLOC_FL_PUNCH_HOLE on a block device sets the REQ_UNAP hints which asks the driver to unmap if at all possible. Note that unmap or not is not a binary decision - typical devices will deallocate all whole blocks inside the range, and zero the rest.
