Hi, I am more of a SCSI guy than ATA so forgive where I am ignorant. The SCSI equivalent to TRIM is called UNMAP. UNMAP is unfortunately only a "hint" to the device so if the device for any reason is busy, it can just do a NO-OP, leave the data as is and still return status SUCCESS. That is not good if you want to wipe data for confidentiality reasons :-) As UNMAP and TRIM are related make sure that TRIM actually provides a guarantee to wipe the data. I do not know ATA enough to know if it does or not. In SCSI, instead of using UNMAP/TRIM you can use WRITESAME10/16 which can be used and which does providde an overwrite/wipe guarantee. Maybe ATA has something equivalent to WRITESAME10/16. I just want to say: be careful, sometimes these commands do not provide a guarantee that they will actually make the data overwritten/unretrievable. ronnie sahlberg On Thu, Dec 6, 2018 at 4:24 PM Robert White <rwhite@xxxxxxxxx> wrote: > > (1) Automatic and selective wiping of unused and previously used disk > blocks is a good security measure, particularly when there is an > encryption layer beneath the file system. > > (2) USB attached devices _never_ support TRIM and they are the most > likely to fall into strangers hands. > > (3) I vaguely recall that some flash chips will take bulk writhes of > full sectors of 0x00 or 0xFF (I don't remember which) were second-best > to TRIM for letting the flash controllers defragment their internals. > > So it would be dog-slow, but it would be neat if BTRFS had a mount > option to convert any TRIM command from above into the write of a zero, > 0xFF, or trash block to the device below if that device doesn't support > TRIM. Real TRIM support would override the block write. > > Obviously doing an fstrim would involve a lot of slow device writes but > only for people likely to do that sort of thing. > > For testing purposes the destruction of unused pages in this manner > might catch file system failures or coding errors. > > (The other layer where this might be most appropriate is in cryptsetup > et al, where it could lie about TRIM support, but that sort of stealth > lag might be bad for filesystem-level operations. Doing it there would > also loose the simpler USB use cases.) > > ...Just a thought... > > --Rob White. > >
