On Thu, Aug 17, 2017 at 10:17:11AM +0200, Christoph Hellwig wrote: > 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. Ok, guarantee in this case is probably too strong expression. But you know what I mean, saying "hey I am not using those blocks, feel free to release them if you can". I did not encounter the need to be so strict about discard, after all, it's for the device benefit. However there are device that do both (discard and zeroout) in discard request and that's what I am after. To be able to identify that's the case and take advantage. I think it's possible now with fallocate FALLOC_FL_PUNCH_HOLE, but I do not know anything in advance and I can't tell whether the device attempted to unmap as well even if it did. -Lukas
