On Thu, Aug 17, 2017 at 11:52:42AM +0200, Christoph Hellwig wrote: > On Thu, Aug 17, 2017 at 10:41:43AM +0200, Lukas Czerner wrote: > > 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. > > That's what the BLKDISCARD ioctl, or fallocate with the > FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE | FALLOC_FL_NO_HIDE_STALE > flags will do fr your. Sure, that's not the problem here. > > > 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. > > With FALLOC_FL_PUNCH_HOLE you know that it is device offloaded. > We don't know that the device won't zero part or all of it, but > then again that was possible before when using BLKDISCARD as well. Do we also know that the blocks were discarded as we do with BLKDISCARD ? > > Now after all that theory: is there a practial issue behind all > this? As I mentioned before. We relied on discard_zeroes_data in mkfs.ext4 to make sure that inode tables are zeroed after discard. Also RHV allows users to set "Wipe After Delete" and "Enable Discard" on the VM disk if it supported discard_zeroes_data. I am trying to find a way to replace this functionality now that discard_zeroes_data always return 0. -Lukas
