how do i securely erase free space on Catalina
With previous OS, you would go to Disk Utility and choose Erase. Now that option is not there.
MacBook Pro 13", macOS 10.15
With previous OS, you would go to Disk Utility and choose Erase. Now that option is not there.
MacBook Pro 13", macOS 10.15
Are you on an SSD? If so, the basic device I/O operations are wildly different from those of a hard disk drive (HDD), and the traditional assumptions based around how hard disk drive erasures work are utterly inapplicable to SSD storage.
Among the differences...
...SSD sectors are erased very shortly after the files are deleted, and must be erased before the storage is re-used, and SSDs work hard to make that erasure happen quickly. This is what TRIM expedites, and macOS supports TRIM.
...SSD sectors cannot be overwritten, due to wear leveling. Among other fundamental differences.
...You can’t write to the same physical sector on an SSD, as sectors are remapped on each deletion, and each rewrite. This due to wear leveling. (HDDs have an earlier form of this, which makes overwriting problematic.)
...The multiple-pattern-overwrite stuff dates back to floppy disks and to 1980s-era hard disk drives, which all had really sloppy head positioning. Modern HDDs, and particularly SSDs, work very differently here.
Encrypt your storage. Storage encryption combined with a secure password protects all of your data, including against any data that might remain on a failing or failed or replaced storage device; including any remaining data in a hard disk free space.
The Secure Erase operation is the analog to a pattern overwrite in a hard disk.
But whole-volume encryption is the preferred approach, and for various reasons.
If you’re even asking about free space erasure, your data storage is likely not encrypted, and you’ll want to fix that now.
Applying old lessons and old remediations against new situations and different platforms doesn’t always end well.
re: shrinking virtual storage allocations for virtual machines
You’ll probably want to contact the folks supporting the virtual machine you’re using.
This’ll involve adding (or using) a tool to send a TRIM, if there’s an SSD in use.
Writing zeros can also work with some SSD controllers, which can convert that zero-sector write into a TRIM.
But best to incorporate this into the VM-related tools, though?
It's not really reliant on the SSD controller - the "hard disk" of the VM is just a file. Yes, it would be nice if it was part of the VM tools, but I suspect difficult to do because every OS has a different way of secure erasing, especially when you're just talking about the free space.
Pay attention to MrHoffman
To supplement his comments. Multi-pattern secure erase shortens the life of an SSD, as the reason for wear leveling is because each SSD physical storage location has a limited number of writes before it fails.
Wasting those writes by repeatedly writing an ineffective secure erase pattern just shortens the life of those cells.
Could you explain why we’re discussing different things?
VMware allocates a honking big wad of storage as a file, and implements a file system within that, correct?
So the storage is all within a file, as far as the host macOS is concerned.
Within that file, the guest operating system does what it expects, though the VM redirects and re-maps those I/O operations into the backing file.
You want that backing file to be smaller, correct?
Which means VMware has to relocate the guest contents—and possibly remap its own storage virtualization as part of that—and then release that storage back to macOS by re-sizing (lowercase-trimming) the backing file. Which the host macOS will respond by issuing (uppercase) TRIM requests at the SSD storage.
You’re trying to do a free-space erase within the guest, and the guest here happens to be macOS, correct?
That erasure with the guest is also rather futile for a macOS guest too, as macOS should have tossed TRIM requests at VMware already. Which means VMware already knows what’s free. Or should. Unless VMware is presenting an HDD to the guest, and not an SSD. Then you’d be stuck with this HDD-era mess, from within the guest. But Apple removed secure erasure with El Capitan. Catalina particularly is not going to appreciate trying to overwrite anything related to the macOS storage.
Which means checking with VMware support.
MrHoffman wrote:
Unless VMware is presenting an HDD to the guest, and not an SSD.
This is the case. The guest OS doesn't see an SSD, just an HDD. So, we need to be able to write zeros for VMware's case. VMware doesn't have an alternate method to do this, but I'm not sure what they could do short of somehow tricking MacOS into thinking that the drive is an SSD and creating a driver that would emulate SSD trim commands. Probably not going to happen, because the type of hardware doesn't matter for either Windows and Linux, and that's where almost all of VMware emulation is.
I'm selling my iMac with Fusion Drive, and having read this thread, I'm sill unclear about whether it's a good idea to wipe the drive or not. I can't do it with Disk Utility or from the command line. It would give me peace of mind to wipe the drive before getting rid of the machine; or is my concern unfounded?
MrHoffman wrote:
If you’ve classified or sensitive data here, then remove the storage from the iMac, and physically destroy it. Fusion drives aren’t worth all that much. For best re-sale value, replace it with an HDD or SSD.
Say what??? A HDD is better than a Fusion Drive? I thought a Fusion Drive was a hybrid - basically, storing the system files on solid state with the rest of the drive being a HDD. This thing boots really fast - faster than any HDD I've ever had.
Regardless, while I appreciate you taking the time to respond, throwing away a perfectly good 3TB Fusion Drive is absolutely out of the question.
I was not aware a Fusion Drive would hurt resale. My experience with the drive over the past 3 years is that's it's been superior to a HDD. At any rate, I've already repartitioned (had a dedicated Boocamp partition) and erased the drive, but I'm certain the HDD portion was not overwritten. I have no desire to open this thing up, so I'll search for a software solution. Thanks for the suggestion, though.
MrHoffman wrote:
What other explanation can there be? Data compression, and copy on write.
Thanks for the reply, but I'm sorry, you lost me there. I have no idea what you're saying. The screenshots depict more than 1 Petabyte of data on a 3 TB drive.
MrHoffman wrote:
Some related reading:
http://osxdaily.com/2016/08/30/erase-disk-command-line-mac/
The article itself seems unrelated, but one comment by a reader seems highly relevant...
Very recently, I came across a situation where Disk Utility could not erase the HDD. Under the strictest supervision from Apple, I was able to do this from the command line. As it was a Fusion Drive, I was then instructed on how to merge or fuse the two disks – SSD and spinning platter. It all worked perfectly in the end BUT this is NOT for the amateur or faint hearted.
I just found this article, which seems to be what I've been after.
MrHoffman wrote:
file copies require negligible additional storage, until the file contents change and start to diverge.
Ok, so you're basically saying what I said - i.e. that the OS handles duplicating files in a very smart and efficient manner - at least disk image files. I wonder if non-disk image files are handled the same way. Hmm...
Still, it's really weird seeing the Finder report more than 400 times the amount of data on the drive than it can actually store.
Shotster wrote:
MrHoffman wrote:
Still, it's really weird seeing the Finder report more than 400 times the amount of data on the drive than it can actually store.
The same way that an app can require more gigabytes of memory than is physically present in the system, using a combination of memory compression, paging and swapping, and backing storage on SSD or HDD;,virtual memory.
Virtual memory is an interesting topic, and storage is well along to being virtualized. Higher-end storage has been virtualized for a decade or two, too.
Computers are not as simple now as many of us had once learned about. And carrying over old ideas and old concepts—non-encrypted storage, erasure, multiple-pass overwrites intended for issues from floppy disk and antediluvian-era hard disk designs long out of use, etc—only serves to get us in trouble.
Yep. It's been removed because it didn't work.
Haven't used VMware in many years, but does it have an option like Parallels to Delete/Remove the Virtual Disk under Hardware?
It does, but I don't want to delete the disk, just shrink the size.
I don't think we're going to be able to get a resolution for this, because we're talking about different things at the end of the day. I appreciate your time though.
how do i securely erase free space on Catalina