The software you used is apparently NOT working correctly. One of your screenshots shows 97MB/s as speed. With that speed, 7-pass of full disk overwriting on a 256GB drive should take around 5 hours. Simple calculation.
You might want to try Blancco 5 instead. As you can see, the link that was for Tabernus Erase LAN is redirected to its site. You may also consider the latest DBAN, which appears to be the free version of Blannco.
To be honest, I've never used any pieces of the above software. I doubt that they are really doing a better job than a simple random overwriting.
Personally, I use shred in GNU coreutils:
shred -v -n 7 /dev/sdX
I won't really use
-n 7 though. At most I'll leave it to the default: 3-pass, and maybe with an extra single-pass zero-filling at the end (
openssl enc -aes-256-ctr -in /dev/zero -out /dev/sdX -pass file:/dev/urandom -nosalt
which you can write a simple bash loop to make it do multiple passes. It does not report progress like
By the way, according to quite some random sources on the Internet (just Google please), it appears that US DoD has already obsoleted the spec(s) for data sanitizing. Now it seems to only recognize physical destruction.
One of the possible reasons, that is of your concern, is that simple overwriting may not "reach" all the reserved space behind the scene on an SSD for so-called over-provisioning (done in the firmware) and/or bad sectors reallocation. Unfortunately, multiple passes of random data filling is probably the best thing you can do, if your SSD does not support hardware encryption.
Do NOT count on ATA DSM/TRIM if you need the data to be securely wiped. TRIM may OR EVEN MAY NOT make the SSD "look" (i.e. hexdump) fully wiped, but it does not actually destroy data behind the scene like overwriting anyway.
One should NOT really trust ATA Secure Erase1 either. ACS standards merely requires it to perform (single-pass) pattern filling. Normal mode should have either zeros or ones as the pattern, while the enhanced mode should have a vendor-specific pattern (but it's still pattern filling) and erase also "Reallocated User Data".
However, the feature set has long been abused by vendors to do non-standard stuff3, when ATA SANITIZE DEVICE had not been introduced. So the behaviour of ATA Secure Erase can be TOTALLY vendor-specific, especially on SSD.
On an SSD, ATA Secure Erase is often implemented as the same thing as BLOCK ERASE of ATA SANITIZE DEVICE, which is pretty much an equivalence of full disk ATA TRIM (on an RZAT2 SSD).
Fixed pattern filling (which might be incorporated in some implementation of "DOD erase" that doesn't have SSD in mind) is not really worth doing because the "smart" controllers in SSD can do compression and even ignore on such repeated overwriting.
If it is really wanted to be done, for some reason, I suppose OVERWRITE of ATA SANITIZE DEVICE is the best way to use. (Since, hopefully, the vendors will make sure that the controller will not "play smart" when the user issue that to the drive.)
On HDD/SSD that has so-called hardware encryption, the enhanced mode of ATA Secure Erase is often implemented as the same thing as CRYPTO SCRAMBLE of ATA SANITIZE DEVICE, which triggers a regeneration of the encryption key and so. It may be the best "quick" method to use if you want to so-called securely wipe the drive, since that's pretty much the whole point of those non-Opal hardware encryption (while people usually wrongly thought its main point is to work with ATA password).
FWIW, one always need to enable the ATA Security feature set first (i.e. "user password") before erasing, which often bricks the drive due to bad implementation (well, or PEBKAC). If the drive supports ATA SANITIZE DEVICE, it should really be preferred. Unfortunately, unlike ATA Security being supported in hdparm, there seems to be no utility supports the more recent feature set yet. One can at best manually form a SCSI ATA PASS-THROUGH command for that and send it with
sg_raw in sg3_utils.
1 The standard command name of ATA Secure Erase is SECURITY ERASE UNIT, which is a mandatory command in the ATA Security feature set
2 Return zeroes data after trim; see ACS standards for its exact definition
3 Specification of Intel 530 SATA SSDs; see "5.3 Security Mode Feature Set"; an example of major vendor "abusing" the ATA Security feature set