Thorough but paranoid: what /disk do I choose for wiping?

[strayduck]

I'm looking to use https://github.com/rentzsch/stressdrive to wipe and test all sectors of an SSD that is plugged in via USB. The README states:

Practically: your device path should always be in the form of /dev/rdiskX (not /dev/rdiskXsX). stressdrive's results can only be trusted if it was allowed to fill the entire device to the device's advertised information-theoretic maximum.

When I diskutil list in Terminal I see this after my internal drive listings:

/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk4
   1:                        EFI EFI                     209.7 MB   disk4s1
   2:                 Apple_APFS Container disk5         1000.0 GB  disk4s2


/dev/disk5 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +1000.0 GB  disk5
                                 Physical Store disk4s2
   1:                APFS Volume EVO                     1.4 MB     disk5s1

Am I reading this correctly that I want to run this against /dev/disk4 as that is the external, physical parent of this external drive and that the "synthesized" /dev/disk5 is just a partition that will be overwritten as part of the /dev/disk4 wipe?

Just being extra paranoid as software like this comes with warnings like:

DANGER: stressdrive will overwrite, without warning, all data on the given drive. Be sure to double-check the drive you're aiming it at (diskutil list or Disk Utility.app > Select Drive > Info > Disk Identifier).

Thanks!

 

[Bigwaff]

Brute-force overwrite method won't work as well for SSDs. Hard drives need multiple overwrites because magnetic media can leave remnants of data, but all SSDs have a limited number of write cycles so overwriting them multiple times will harm the drive's longevity.

You can encrypt the external drive using Disk Utility which means a password would be needed to decrypt the drive. After encrypting the drive, simply perform a normal erase and format using Disk Utility. Any data on the drive is impossible to decrypt w/out the original password used during encryption. You've essentially "wiped" the SSD.

What is the brand and model of SSD (not the external enclosure but the actual SSD component)? Why would you want to "stress" the SSD by writing garbage data on it and shorten its useful lifespan?

 

[strayduck]

Thanks for the reply. It sounds like I need to clarify a couple of points from above:

• The disk is a Samsung Evo 860 which spontaneously unmounted and became unreadable. I was able to to format it using Disk Utility but would like to test the integrity before putting it back into service or RMA-ing it
• While the name "stressdrive" might make it sound like the software's purpose is to thrash a disk for fun and reduced lifespan, the intended purpose here is to simply write data across all available sectors once and read it back to confirm there aren't fundamental problems with the drive. The description makes it sound like this is achievable, even on an SSD where the controllers decide where the data goes
• With a TBW rating of 600TB I'm willing to "sacrifice" a measly 1TB to ensure things are in good working order as these drives have a reputation for exceeding their ratings

 

[Nermal]

Also note the difference between /dev/disk and /dev/rdisk. Both map to the same disk, so once you've confirmed the number be sure to add the "r".

 

[gilby101]

You can encrypt the external drive using Disk Utility which means a password would be needed to decrypt the drive. After encrypting the drive, simply perform a normal erase and format using Disk Utility. Any data on the drive is impossible to decrypt w/out the original password used during encryption. You've essentially "wiped" the SSD.

This bothers me. My understanding is that encrypting a volume ensures that data currently on the volume along with future data is encrypted. This leaves the rest of the APFS container unencrypted. So unless the drive has always had encrypted volumes, I worry that your process does not touch fragments on the unencrypted parts of the drive which have not been overwritten by the newer erase and encrypt. Hence the need to do an "erase" pass on the whole drive.

 

[Bigwaff]

So unless the drive has always had encrypted volumes, I worry that your process does not touch fragments on the unencrypted parts of the drive which have not been overwritten by the newer erase and encrypt. Hence the need to do an "erase" pass on the whole drive.

We’re getting a little off topic after @strayduck response but you have a good point if we stay in macOS world. You would have to encrypt all volumes. TRIM support takes care of the rest. However, best and sure way is for one to use manufacturer utilities (on Win or Linux) to access secure erase feature of the SSD drive firmware. Poof! Data gone.

 

[strayduck]

Also note the difference between /dev/disk and /dev/rdisk. Both map to the same disk, so once you've confirmed the number be sure to add the "r".

@Nermal: Tell me more. Is this because the software will be looking for the "r" and will fail to find the drive if it is absent or does the "r" represent something different? I ask because I've never seen this on Mac and wondering if this is a Linux-specific thing?

@gilby101 and @Bigwaff: Yes, we are drifting a bit, but it's an interesting discussion. The "paranoia" I refer to in my post title is the paranoia of targeting too little or too much of the drive (or the wrong drive entirely). 😅

So are we all in general agreement that if the drive assignments have not changed on this system, to fill up this disk with data, I'm targeting /dev/rdisk4?

 

[Brian33]

So are we all in general agreement that if the drive assignments have not changed on this system, to fill up this disk with data, I'm targeting /dev/rdisk4?

Given the 'diskutil list' output in your first post and the instructions for stressdrive, yes, I agree that's the proper target. But I'm just some random guy on the internet! Also, I don't really understand the difference between /dev/disk4 and /dev/rdisk4.

 

[strayduck]

I did a little more digging and this superuser thread has some good info:

In OS X each disk may have two path references in /dev:

/dev/disk# is a buffered device, which means any data being sent undergoes extra processing.

/dev/rdisk# is a raw path, which is much faster...

There is also a Reddit thread that corroborates:

The "r" device is the raw one. It will let you write 1 byte at a time. The other device is the block device for normal io. Normally, raw would be used for config stuff or raw access to a partition. Most disks won't accept IOs smaller than a block.

 

[Nermal]

@Nermal: Tell me more. Is this because the software will be looking for the "r" and will fail to find the drive if it is absent or does the "r" represent something different? I ask because I've never seen this on Mac and wondering if this is a Linux-specific thing?

As you've noticed, the "r" means "raw". I'm not too sure of the specifics of how it all works, but with the Stressdrive docs saying to use it I just wanted to make sure that you'd noticed it. It's not a Linux thing.

 

[Fishrrman]

Forgive my ignorance:
Will disk utility do a secure erase on an external SSD? Or does it offer that option only for platter-based HDD's?

If it can, use it (and be done with it).

If it CAN'T, a suggestion I've posted before:
Get ahold of an old copy of Drive Genius.

Then...
Use disk utility to "erase" the entire drive (even if it's NOT a secure erase).
IMPORTANT: erase to HFS+ (Mac OS extended, journaling enabled, GUID partition format).
DO NOT erase to APFS !!!

Then...
Open Drive Genius and select the "Shred" option.
DG should see the HFS+ formatted SSD.
Use DG to zero out the data.

When done, if you want APFS, use disk utility one more time to erase to APFS.

That was easy...

Personal experience:
DG will even "shred" the unused space on my INTERNAL Apple SSD on my 2018 Mini (it has partitions formatted to HFS+).

 

[strayduck]

Thanks @Fishrrman. To oversimplify, you're right that Disk Utility (and probably also Drive Genius) are for platter-based HDDs. The controllers on the SSDs decide where the data goes and depending on wear and many other factors, might take the incoming data and simply overwrite the same sectors.

Stressdrive is going to fill the drive with real data that can be read back, and keep filling it to the limit of the drive, which will force the controller to hit all the sectors.