On Fri, Oct 19, 2018 at 05:00:33AM -0700, Christoph Hellwig wrote: > On Fri, Oct 19, 2018 at 02:49:44PM +0300, Vitaly Chikunov wrote: > > On Thu, Oct 18, 2018 at 11:19:45PM -0700, Christoph Hellwig wrote: > > > Just as a note: the name is a complete misowner, a couple overwrite > > > are not in any way secure deletion. So naming it this way and exposing > > > this as erase is a problem that is going to get back to bite us. > > > > In what way it's not secure deletion? > > > > It's secure deletion by overwriting discarded data instead of leaving it > > as is. > > Overwriting data does not delete data. Most certainly not in Flash based > SSDs, but also not in many storage arrays, or for that matter many modern > disks that have sectore remapping and various kinds of non-volatile > caches. There is a reason why devices tend to have special commands to > perform secure erase - depending on the media they might or might not > overwrite internally, but at least they do it in a way that actually > works for the given media and device configuration. I know that. This is why it says "The target does not try to determine if the underlying drive reliably support data overwrites, this decision is solely on the discretion of a user. Please note that not all drivers support this ability." > > dm-erase or dm-wipe? dm-discerase? > > dm-overwrite? These are all good to me. > > > But still provide REQ_OP_SECURE_ERASE support? > > On the one hand that is highly misleading and would warrant a warning > (see above), on the other hand discard is purely advisory and can be > skipped any time, including by intermediate layers. So I don't think > you can actually do what you want without major changes to the whole > I/O stack. Probably, a concerned user should test his setup to be sure discards reach dm-secdel (after that they go as writes), and data he thinks should be erased is erased.
