4 ms·
Unrelated to trim, but for some reason when I used secure erase on an SSD with a ZFS pool, the pool was still able to be found by ZFS. That shouldn't be the ca
by tripdout 4y ago
Unrelated to trim, but for some reason when I used secure erase on an SSD with a ZFS pool, the pool was still able to be found by ZFS.
That shouldn't be the case, right?
- h506001 4y agoNot sure how secure erase works, but I’ve run into this a few times after “erasing”. I think it has something to do with boot records or partition tables. So there’s a piece of some drives (usually at the front) that contains this data. You can overwrite it properly with the appropriate tools. I always just used `dd` on the raw drive ref in Linux to blow it up.
- avianlyric 4y agoI think ZFS identifies drives by their serial number. So you can erase a drive in a pool, and ZFS on that machine will still recognise the drive based on its serial number, and know its pool membership. ZFS should then throw all kinds of errors once it notices that all the super locks and other FS metadata is missing. But a scrub should cause ZFS to simply fix that via normal resilvering.
- anecdotal1 4y agoNo, ZFS identifies by finding superblocks. This drive was not securely erased if any superblocks could still be found.
- ridgered4 4y agoSecure erase depends upon the drive firmware correctly implementing the function. The only study I've seen that actually tested this found about half of drives did not do it properly! But that was from 10 years ago now. I once used secure erase on a nvme SSD and found some of the partition table was still present when going to reformat, even though the operation indicated success. I eventually tracked it down to the drive being mistakenly mounted at the time of the secure erase. So there is your other failure mode, making sure you and your software utilities also perform the secure erase correctly.