On Mon, Feb 8, 2016 at 3:18 PM, <m.roth at 5-cent.us> wrote:> Chris Murphy wrote: >> DBAN is obsolete. NIST 800-88 for some time now says to use secure erase >> or enhanced security erase or crypto erase if supported. >> >> Other options do not erase data in remapped sectors. > > dban doesn't? What F/OSS does "secure erase"? And does it do what dban's > DoD 5220.22-M does?http://dban.org/download That DoD standard is also obsolete per NIST 800-88. There's zero evidence provided that 2 passes makes any difference compared to 1, let alone doing 7. hdparm --security-help This takes the form of something like: hdparm --user-master u --set-security-pass chickens /dev/sdX hdparm --user-master u --security-erase-enhanced chickens /dev/sdX The 2nd command doesn't return until completion. hdparm -I can give an estimate of how long it will take. For HDDs I've found it slightly overestimates how long it will take, but is generally pretty close. For SSD's it can be way off. It says 8 minutes for my SSD, but the command returns in 5 seconds and the SSD spits back all zeros. Secure erase is really the only thing to use on SSDs. Writing a pile of zeros just increases wear (minor negative) but also doesn't actually set the cells to the state required to accept a new write, so you've just added a lot more work for the SSD's garbage collector and wear leveling, so it's going to be slower than before you did the zeroing. Secure erase on an SSD erases the cells so they're ready to accept writes. -- Chris Murphy
On Mon, Feb 8, 2016 at 10:54 PM, Chris Murphy <lists at colorremedies.com> wrote:> Secure erase is really the only thing to use on SSDs.Oops. It's probably a fairly close approximation to just mkfs.btrfs -f (or xfs) the entire block device for the SSD. If the kernel sees it as non-rotational, it'll issue a whole device trim first, then write out scant amount of metadata (btrfs writes out a tiny amount of metadata at mkfs time, xfs a bit more, ext4 a lot and then even more after mounting). For most people this is probably a lot easier than the multistep process using hdparm and secure erase. -- Chris Murphy
On 2/8/2016 9:54 PM, Chris Murphy wrote:> Secure erase is really the only thing to use on SSDs. Writing a pile > of zeros just increases wear (minor negative) but also doesn't > actually set the cells to the state required to accept a new write, so > you've just added a lot more work for the SSD's garbage collector and > wear leveling, so it's going to be slower than before you did the > zeroing. Secure erase on an SSD erases the cells so they're ready to > accept writes.at least one SSD I had, the vendor told me writing a full pass of zeros on it via dd or whatever would completely reset the garbage collection and effectively defrag it. -- john r pierce, recycling bits in santa cruz
On 02/08/16 23:54, Chris Murphy wrote: <<>>> hdparm --user-master u --set-security-pass chickens /dev/sdXcentos 6.7, hdparm v- 9.43; hdparm --user-master u --security-set-pass chickens /dev/sdX -- peace out. If Bill Gates got a dime for every time Windows crashes... ...oh, wait. He does. THAT explains it! -+- in a world with out fences, who needs gates. CentOS GNU/Linux 6.7 tc,hago. g .
On Mon, Feb 8, 2016 at 11:18 PM, John R Pierce <pierce at hogranch.com> wrote:> On 2/8/2016 9:54 PM, Chris Murphy wrote: >> >> Secure erase is really the only thing to use on SSDs. Writing a pile >> of zeros just increases wear (minor negative) but also doesn't >> actually set the cells to the state required to accept a new write, so >> you've just added a lot more work for the SSD's garbage collector and >> wear leveling, so it's going to be slower than before you did the >> zeroing. Secure erase on an SSD erases the cells so they're ready to >> accept writes. > > > at least one SSD I had, the vendor told me writing a full pass of zeros on > it via dd or whatever would completely reset the garbage collection and > effectively defrag it.Yes it'd be "defragged" in that it has no file system at all to be fragmented in the first place (easier done with a mkfs). But a huge percent of the available cells on the drive (the portion not overprivisioned) would contain valid data (zeros) as far as the drive firmware is concerned, and those cells storing zeros are not in a state to accept writes. So unless it's a very good SSD that's so overprovisioned that it can perform well without the benefit of trim, and some can, this is odd advice. It's much simpler to just do a full device mkfs, which will do a whole device trim, and if you want you can then use wipefs to remove that filesystem's signature. -- Chris Murphy