On Mon, Aug 10, 2020 at 09:24:57AM -0400, tytso@mit.edu wrote:

Part of the problem here is that discard is being used for different
things for different use cases and devices with different discard
speeds.  Right now, one of the primary uses of -o discard is for
people who have fast discard implementation(s and/or people who really
want to make sure every freed block is immediately discard --- perhaps
to meet security / privacy requirements (such as HIPPA compliance,
etc.).   I don't want to break that.

Note that discard does not provide any security whatsover.  For one
none of the underlying primitives actually gurantee any action, the
device is free to always ignore parts or all of a discard request.

And even if it didn't that doesn't mean that data couldn't easily
recovered from the media.

We now have a requirement of people who have very slow discards --- I
think at one point people mentioned something about for devices using
HDD, probably in some kind of dm-thin use case?  One solution that we
can use for those is simply use fstrim -m 8M or some such.  But it
appears that part of the problem is people do want more precision than
that?

Device managed SMR drivers usually support TRIM.  But it actually
should be a decently fast operation usually, as those drives have a
remapping layer just like a FTL.