Exactly, that's my point, this alleged high SSD use was fixed two macOS versions ago, why is this even still being discussed?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
ssd swap - high usage of Terabytes Written
- Thread starter Forti
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
While using LR Classic, the swap and memory pressure both goes up. But when I'm done and close LR, the swap remains at whatever level it was at during use, while the memory pressure goes back to green. I thought swap meant it is using the internal SSD, and because I don't want it to keep using the SSD as RAM to preseve the lifespan, I want to clear it back to zero. The only way to do this seems to be restarting the mac. I wish it could be done with just a terminal command or another way without the restart, that's all!
Edit: I'm running Catalina if that makes a difference. And my SSD is perhaps on its last legs - 512GB from 2012.
Last edited:
If you have built-up swap after closing the software, it stays there just in case and doesn't do any damage at all by sitting there - because the initial damage is done by writing/erase/write/read.
After you close your LR, swap is only in read mode so doesn't hurt further. If dropping the number to 0 helps you visually then you are of course can restart but it doesn't do anything.
Under 50 gb? Erasing is a free exercise, while expanded macos i think weighs in at 40 gb of data.
Erasing an SSD uses very few writes. The "secure erase" that actually overwrites data isn't needed. So the number of writes is just the size of the OS being installed.
Where is the “secure erase” option located? I don’t recall seeing that. I do think
I killed the partition and formatted on one machine. Does formatting write to every cell? If so, this must use a lot of writes - the size of the disk itself?
That was my thought, but wasn’t sure. I’m under the impression that when wiping the disk, just the encryption keys are deleted. Is this correct?
Why erase, just reset the Mac and your done. Erasing the drive can get you into trouble if your not carful and can only be recovered by another Mac.
Q-6
I agree with you, but I did wind up erasing. I’m not going to do that going forward. Any pointers (links, threads) as to why or what kind of troubles it can cause by erasing and repartitioning???
I’m still curious as to the writes involved after an erase.
The technical term is "create a new file system on the device". The word "erase" is Apple's invention that I think was designed as a warning about losing data. No one ever said "erase" until Apple started to use that term. And the word "Format" is a holdover from the days of floppy disks on DOS systems. Microsoft kept using the word "format" long after the floppy was dead because it is what users understood. In those days we had to write a continuous stream of data after the index hole was detected to create sector markers on the floppy disk.
With hard drives (and SSD) all you do is write an empty root directory structure and place all the other sectors on the "free list". OK, the exact details depend on the file system being created but in all cases, all you do is write a small data structure to the disk. Many file systems have redundant data structures and checksums so there is a little more to write. But still, this amounts to a very tiny fraction of the size of the device.
With magnetic media like disks, writing data left some residual magnetism on the drive. So they offered a "secure erase" that wrote random data all over the disk many times. So it might take 500 gigabytes of writing to fully overwrite a 100-gigabyte hard drive. SSDs do not have this issue. So the option is not offered.
All of this technology long predates macOS. MacOS is based on BSD UNIX which can trace its origins back in 1968. Surprisingly little has changed in the last 50 or so years. Everything I wrote above would have been true 50 years ago.
Specifically there were (or still are?) 7 or even 35 pass zero-writing procedure that you can do in Mac OS Disk Utility. Like the poster said above, this was meaningful when dealing with hard disks due to its nature of retaining data if you "only" do the index formatting. With SSD I am positive this is no longer needed.
It doesn't matter either way. Everything on the HDD or SSD is encrypted by FileVault 2, delete your user account and with it the master key from the security enclave and there is no readable data left on the drive. Zero-writing the whole drive is not necessary even once.
It would actually be harmful to do zero writing on an SSD as it would be doing major wearing out of write cycles on the SSD therefore at considerable cost and with no benefit.Specifically there were (or still are?) 7 or even 35 pass zero-writing procedure that you can do in Mac OS Disk Utility. Like the poster said above, this was meaningful when dealing with hard disks due to its nature of retaining data if you "only" do the index formatting. With SSD I am positive this is no longer needed.
I lost track of the origin of this discussion, was it only concerned with the boot volume with modern macOS?
FileVault didn’t exist a few macOS versions ago, and then it was optional for a while as well. Also obviously when using external DAS you are still free to make it vanilla unencrypted, even for external SSD on APFS I think. So in some ways this function can still be useful, just not as much as before.
In fact I was also somewhat puzzled how this was brought up within this SSD wearing thread. But if someone’s top priority is to eliminate his/her data being compromise after a disk wipe, it is a good chance the disk is being discarded / sold / giveaway anyway. The remaining write cycles is less of a concern then. I’d say even with hard disks a 35-pass zero-out will measurably shorten its life span as well. I don’t think any conventional digital carrier so far wouldn’t suffer at least a bit with that much intentional writing.
FileVault is a very old feature, not a young one. FV 1 (encrypted disk images for user home folders) shipped in Mac OS X 10.3 Panther in 2003, 20 years ago (before the Intel transition!). FV 2 (full disk encryption) debuted in 10.7 Lion in 2011.
On Apple Silicon or T2 Macs, the internal SSD data volume is always encrypted and its volume encryption key (VEK) is always stored in the Secure Enclave. Here, the only difference between FileVault's "on" and "off" states is the hierarchy of secrets required to decrypt the VEK. While FV is on, two secrets are needed. One is a unique ID stored inside the Secure Enclave, the other is the user's password. When you turn FV off, all that changes is that the VEK is re-encrypted to only require the unique ID.
The VEK is quite small and completely contained in the Secure Enclave, so changing FV state or wiping the data volume are both fast operations which generate no write cycles.
Brute force erase techniques are mostly pointless here. The only exception is if you're exceptionally paranoid and are worried that someone who is capable of breaking the crypto algorithms Apple used is after your data. Since this is extremely unlikely (there are no publicly known weaknesses in those algorithms), 99.9999999% of people should just open System Settings, click "General", then "Transfer or Reset", then "Erase All Content And Settings".
Thank you for the detailed response. I actually started using OS X since 10.1 or 10.2, so my fuzzy memory served me wrong as I seriously don't remember FileVault existing for that long. Maybe Apple didn't start to advertise it up front until much later, in my memory it was probably around Mountain Lion or even later when it started getting widespread use and was being discussed by average users.
And yes, the key moment was when security enclave started being present on Macs since T2, that's when encryption on by default wouldn't introduce performance penalty (?). At this point I agree we can officially say it started become quite pointless for an average Mac user to to multi-pass zero-out for a Mac centric drive, especially the boot volume.
By the way I wonder how much of this can still hold true in the face of security enclave breach. If I am not wrong, T2 and M1 gen are already compromised (I am not expert on this, just read this somewhere that there is a vulnerability). But that breach requires the drive to be on the same Mac as it was, you can't detach (a DAS) or even remove the board with NANDs and expect to do anything with the data.
I think you're right that widespread use didn't happen till around Mountain Lion. FV1 had lots of quirks and performance issues, FV2 was when they first delivered nearly seamless high performance encryption.
Not a coincidence: Apple released FV2 only after Intel added AES-NI cryptographic accelerators to all their CPUs. You could enable FV2 on Macs which lacked AES-NI CPUs, but it cost a lot more performance, both disk and CPU.
As mentioned, by the time FV2 rolled out, on sufficiently new Intel Macs, you could turn it on with nearly zero performance loss. The Secure Enclave approach has even less overhead than that, but I remember enabling FV2 on a 2011 MacBook Air and not noticing any difference.
I don't recall any secure enclave breaches. The T2 issue was a jailbreak which allows someone with physical access to the device to boot unsigned code. As far as I can tell from various articles about it, the "Checkm8" bug exploit can't be used to decrypt data on the SSD. This is because the bug targeted by Checkm8 lies in the boot ROM used to start up the main "application" processors, not the boot ROM for the special Secure Enclave Processor (SEP). Checkm8 can boot a modified OS, but it can't force the SEP to decrypt an encrypted volume without a user entering the secret protecting it.
T2 was derived from A10. The Checkm8 jailbreak affects seemingly everything up to and including A11, and was fixed in A12. M1 is A14 generation, so it's not affected. (That said, Apple's revised Secure Boot for M series SoCs allows Mac owners to "jailbreak" already - no need to use an exploit tool like Checkm8, you just follow directions for configuring the Mac to a lower security state. This is how Asahi Linux for Apple Silicon works.)
Again thanks for your insights. Me calling the T2 issue a "breach" was exaggerated since I wasn't understanding it at all which you laid it out clearly here. So the point of bringing that up and getting an assured response like yours above is to confirm the encryption approach by Apple is sufficient for data privacy, and it seems to still holds itself.
The FV performance penalty was considerable, I remember discussing the trade off with enabling it. The case in point was for a MacBook deployed for trips, and then the external DAS with business data etc. With FV2 I vaguely remember the performance hit was still there, it's not negligible but not unacceptable either. To be honest the main issues with FV were compatibility / accessibility than these.
Macbook Air M1, 8GB, 512GB, after close to 3 years of pretty heavy use. 1.15PB written is just 36% used? I guess I'm really flogging the poor fellow, but this would suggest I'm still projected to get another ~6 years out of this SSD at the current rate for a total of over 3PB units written? This seems high. How trustworthy is this data?
Code:
SMART/Health Information (NVMe Log 0x02)
Critical Warning: 0x00
Temperature: 29 Celsius
Available Spare: 100%
Available Spare Threshold: 99%
Percentage Used: 36%
Data Units Read: 2,465,964,738 [1.26 PB]
Data Units Written: 2,259,276,748 [1.15 PB]
Host Read Commands: 11,186,856,131
Host Write Commands: 6,580,282,414
Controller Busy Time: 0
Power Cycles: 300
Power On Hours: 4,931
Unsafe Shutdowns: 49
Media and Data Integrity Errors: 0
Error Information Log Entries: 0Interesting data point! Thanks. Now that the M1 Macs have been out for nearly three years there must be a few more high usage ones around.
I sold my M1MBA 512/16 with 80 TBW 3% usage. So at that rate it would reach your 36% usage at nearly 1PB. Not very different from your 1.15PB.
The arithmetic is not very accurate because I don't know exactly when mine flipped from 2% to 3%. Also don’t know how my 16GB RAM vs your 8GB affects it. Presume more RAM less TBW.
What is very different about your data is that you reached 1.15PB in three years, and I only reached 80TB in two years.
What your data point shows is that we don't need to be concerned about 1.15 PB, probably much more. At my rate of usage I wouldn’t have reached 1.15PB for 28 years!
I haven’t answered your question and I don't believe anyone can. Need more very high TBW users like you to keep reporting what the numbers show and especially if any problems start.
Last edited:
If these numbers are accurate, Apple SSDs endurance is in the enterprise class. 3PB TWB for a 512GB SSD translates to 3 DWPD for 5 years, which is pretty much the best you can get. That's 10 times higher than best consumer SSDs. And enterprise SSDs tend to be rather expensive.
Apple has a history of combining enterprise-level and consumer-level technology in one reduced cost product (e.g. Fusion Drive, RAM packaging on Apple Silicon Macs, and I'm sure we will see error-corrected RAM on the Mac very soon). Maybe they do something similar with their SSDs. Consumer/enthusiast performance with enterprise-level reliability. Could help justify their high SSD costs a bit...
Apple has a history of combining enterprise-level and consumer-level technology in one reduced cost product (e.g. Fusion Drive, RAM packaging on Apple Silicon Macs, and I'm sure we will see error-corrected RAM on the Mac very soon). Maybe they do something similar with their SSDs. Consumer/enthusiast performance with enterprise-level reliability. Could help justify their high SSD costs a bit...
I don't know how trustworthy the estimated 36% is, but the fact that your drive isn't already dead with over 1PB written and there aren't any reported errors is very promising for you and good news for the rest of us
