Very wise precaution! So the cat </dev/zero part on its own is harmless. You want to be sure the output has the right target. Using the template @ron gave you above, you have by now likely a best guess of that target. Let’s say you’re pretty sure it’s /Volumes/TroublesomeSSD/bigtempfile. Try this command first, just to validate the target:
echo "TidBITS Talk is wonderful!" > /Volumes/TroublesomeSSD/bigtempfile
That will complete in an instant. Then, if you see the file bigtempfile on your SSD, you’re in business. If not, you’ve only written a 26 byte file to the wrong target.
Much simpler than that. In a terminal window, enter the following command:
ls /Volumes
The list you get back has the potential targets for @ron 's command. For example, on my computer, I get:
12:17 PM ~ > ls /Volumes
Macintosh HD Time Machine
Because I have only my internal boot drive (Macintosh HD) and one external drive (Time Machine). So lets imagine when you run this command on your computer, the result is:
12:17 PM ~ > ls /Volumes
Macintosh HD Time Machine TroublesomeSSD
There’s the name of the drive you need to target for the cat command. So the complete command would be:
You can ignore the Preboot, Recovery, and 11.4-GB system volume. Those get set up by any modern macOS install, but they contain no private information at all. They can be found in exactly that configuration on any modern macOS system. The only partition you write private data to is the one with “Data” appended to it. That is the one you need to be concerned with.
Fortunately, due to the way Apple has firmlinked these partitions, you access that volume (/Volumes/CCC_Clone - Data) when you call /Volumes/CCC_Clone, as @fischej points out above. Since the /Volumes/CCC_Clone system partition is read-only (except for the macOS installer/updater), any of your attempts to write to it would fail anyway, so they cleverly get rerouted to /Volumes/CCC_Clone - Data by macOS right away. When you view any of the partition through Finder all of it will appear as one contiguous volume, again thanks to the way Apple has cleverly firmlinked these read-only and read/write volumes. You need to know exactly where to peek to see that some parts of it come from the read-only system partition while other are writable as they reside on the Data partition.
TRIM has been specified for the following interfaces:
ATA (including SATA) has the TRIM command
SCSI has the UNMAP command
SD/MMC cards (including eMMC drives) have the ERASE command
NVMe has a generic “dataset management” command that includes a “deallocate” sub-command
Of note is that USB does not include any such command in its mass-storage class (MSC) protocol. But an enclosure that supports USB-attached-SCSI (UAS) might support the SCSI UNMAP command.
So if you want to perform TRIM on a USB device, the device’s USB bridge chip will need to implement UAS and must be able to map the SCSI UNMAP command onto the appropriate command for the internal SSD (TRIM if it is SATA, or deallocate if it is NVMe), in addition to the internal SSD having support.
And, of course, macOS needs to send the command, which may require third-party software support and/or use of the trimforce command.
A Thunderbolt-attached drive is effectively a PCIe-attached drive, which greatly simplifies everything:
An NVMe device will appear as if it was directly connected to you motherboard (since NVMe is based on PCIe).
A SATA devie will appear as if it is connected to a SATA host adapter. Since SATA host adapters are very simple (typically just passing ATA commands to/from the connected device), it should support TRIM if the drive itself does.
After erasing the drive (either via a single-pass erase or reformatting it with TRIM), any residual garbage data would only be accessible by bypassing the SSD controller.
It’s definitely doable, but it would require either replacing the SSD controller’s firmware or removing the flash chips and connecting them to something else. I don’t know how hard this would be, but it is definitely not something that a service tech would do as a part of the work he’s being paid to do, since it would be time consuming, would probably render the SSD unusable, and might require specialized equipment.
Just to be sure I understand: you mean
1- fill up with date
2- erase with new encrypted format.
My point is that there is no encryption without erase, at least in disk util as far as I understand ? I don’t see a way to take a disk with data and just encrypt it.
the setup is Mac OS Catalina, 1TB primary drive and 2 TB external SSD renamed TroublesomeSSD (no spaces). The difference is size makes it easy to see which disk in the list is primary vs external SSD.
when I run diskutil list, I end up with a myriad of disks in the identifier column, synthetic and physical etc
based on my probably false understanding of your post, I opted to
diskutil secureErase 4 disk3s1 (because it’s the line with the actual name of the disk I want to delete) and ended up with the error message below.
Instead of just trying each disk in the identifier column one by one, by trial and error, I am opting to contact you yet again to understand the problem and then enter the right command.
You need to know exactly where to peek to see that some parts of it come from the read-only system partition while other are writable as they reside on the Data partition.