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:

quoted

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.

quoted

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