Tuesday, July 14, 2020

APFS Snapshots of the Big Sur System Volume

Jeff Johnson:

Yesterday I updated from Big Sur beta 1 to beta 2, which went smoothly except for the fact that the update doubled the size of my read-only system volume to over 27 GB, which didn’t leave me enough free space on the partitioned external disk to install (the enormous) Xcode. Without Xcode, it’s impossible to adequately beta test Big Sur as a developer. It turns out that Big Sur always boots from a snapshot (an APFS snapshot that you can see with diskutil apfs listSnapshots, not a Time Machine snapshot that you’d see with tmutil listlocalsnapshots), and updating to beta 2 apparently added a new snapshot without deleting the old snapshot. I tried to delete the old snapshot, which was listed as “Purgeable” by diskutil, but Big Sur claimed I lacked permission, even with SIP disabled.

Howard Oakley:

Not only does Big Sur use a snapshot of the current system for its Signed System Volume, but it makes and keeps one of your previous installation too. When your startup disk has half a terabyte free, that may escape notice, but for us lesser mortals, and anyone trying to manage Big Sur in less than 100 GB, it really gets in your way. I’m sure that those figures will improve by the time that Big Sur is ready for release, but that isn’t the point: once the system has made that snapshot of the previous installation, there seems no easy way to discover how much disk space the snapshot is occupying, and the only way to free up that space seems to be performing a clean install of macOS.

[…]

If you really want to know what’s going on with your snapshots and why free storage space is disappearing, the best tool at present is Carbon Copy Cloner.

[…]

We need Disk Utility to be able to list all snapshots stored on a volume, and their current effective size, together with a command to delete those which are purgeable. Is this really too much to hope for three years after Apple introduced APFS and snapshots?

Previously:

Update (2020-07-30): Erik Gomez:

Worse is you actually can’t use time machine in recovery OS to revert to any of these snapshots. Every time I try, it fails.

20 Comments RSS · Twitter

Just the worst news for anyone who bought a Mac as recently as April of this year with a 128 GB SSD.

the update doubled the size of my read-only system volume to over 27 GB

[..]

updating to beta 2 apparently added a new snapshot without deleting the old snapshot

And…

it makes and keeps one of your previous installation too.

Soooo each of those two snapshots takes up about 14 GB? Aren’t these snapshots supposed to be differential? Or does the encryption break that?

APFS is a dumpster fire. I'm scared to let my internal disk get below 50 GB free now, which sucks because that's 10% of the space. For some reason, Finder will report that I have, say, 38 GB free space. Then suddenly Mail will freak out saying I have no disk space left, and a minute or so later my entire Mac will go nutz, with other apps reporting all kinds of weird errors, being unable to quit, unable to empty the Trash, etc.

It's a nightmare. How can I simultaneously have 38 GB free space but also have near zero free space? Who knows. It was never like this until APFS came along. I could empty 100 MB from the trash and the Finder would instantly show that I had an extra 0.1 GB free space. Now I can empty the trash all day long and still have the same "free space" that I had in the morning.

Many, many other people report the exact same thing, I KNOW there's no way Craig Federighi hasn't either experienced it himself or heard about it directly from someone inside Apple. It's just too common. Yet here we are, years later, and something basic like accurate and timely reporting of free disk space is totally broken!

We need someone like Swisher, Levy, or Mossberg to write about it in a national newspaper before it will get fixed. Sad but true.

@Ben This just happened to me today. Finder showed 33 GB of free space at the same time a window popped up saying I was out of space. I had a ton of stuff in the trash (none of the files were clones), emptied it, and the reported numbers didn’t change.

@Michael That's very strange because since I really started paying attention to it a couple months ago, every time it happens to me the Finder reports 30-something GB of free space. It never reports 42 or 23 or 12 GB free space. Always something in the 30s range. But it doesn't always occur... I can sometimes go down to, say, 17 GB free space for a while and it's fine. It's unpredictable, like a bomb waiting to go off, which is why I finally settled on trying to keep my free space above 50 GB at all times. Also sometimes if I go to About This Mac, and click on the Storage tab, it gives what appears to be a more accurate assessment of my free space vs the Finder. Right now ATM is reporting 24 GB free space, Finder says 20 GB. Who knows.

And this is interesting:

Finder says: 20 GB
ATM says: 24 GB

Move 12 GB folder to Trash, empty it.

10 seconds later,
Finder says: 20 GB
ATM says: 41 GB

24+12 = 36... where did the other 5 GB come from?

3 minutes later, Finder still says 20 GB! It will probably be like this hours from now. Whatever method ATM is using, the Finder should use... *sigh*

Jean-Daniel

If you want to get free space back, you should always purge the local Time Machine snapshot too, as deleted files are still present in the snapshot (that's why emptying the trash does not free space).

> tmutil deletelocalsnapshots /

Note that this call is still asynchronous, and you will not immediately see all the space available. You still have to wait a couple of minutes until all snapshot are effectively destroyed (you can see the free space increasing progressively in the Finder window or elsewhere).

SSD drives welded permanently into the MLB. Now Tim's Apple is replacing TargetDiskMode is BS OS with SMB. Then there's this nonsense where they'll lock down Recovery Mode, which is, on a surface level, a stupid trade-off, since it's "game over" when the attacker has physical access.

Basically Apple, in its pursuit of artificially pumping the Services revenue column, is coming for your data. It would be in the best interest of users to open both the iPhone and Mac. But that won't do for Apple, because they'd miss out on the opportunity to control your most important data (your photos, videos, work documents, etc).

Apple needs for the Mac to be as hobbled as the iPhone, so they can coerce users into backing up "in the cloud" (if you care about security, backing up to the cloud is a horrible idea, by the way). Apple need to make sure you can't easily transfer files from other companies, without going through the App/iTunes Store or iCloud.

That's my take, for what it's worth. I'm learning Elementary. I want off.

I’m one of the poor suckers stuck on 128GB. I have a 2014 MBP, so I can technically replace the drive...

Has anybody had experience with those cheap mbp compatible pcie drives on eBay?!

It’s either that or a used apple ssd, both are similar prices, but the used drives are obviously likely to fail sooner...

@Adrian Why not get a brand new one from OWC or equivalent? The 1 TB drives are cheap nowadays. Or maybe your model is really hard to upgrade and they don't have parts?

I’m scared to let my internal disk get below 50 GB free now, which sucks because that’s 10% of the space. For some reason, Finder will report that I have, say, 38 GB free space. Then suddenly Mail will freak out saying I have no disk space left, and a minute or so later my entire Mac will go nutz, with other apps reporting all kinds of weird errors, being unable to quit, unable to empty the Trash, etc.

I had catastrophic problems with this in 2018, at least twice.

I figured it was something between the way purgeable space works, and the way VMware relies on free space to make certain decisions. That is, macOS assumes “sure, there’s not a lot of free space, but it doesn’t matter; I can purge this data if space gets even tighter”, whereas VMware thinks “oh crap, we’re running out of space; mayday!”

For some reason, that interaction (I presume) led to my VMs becoming irrecoverable. I had to set up completely new ones. That’s why I know about 2018: because my newest Windows installation is from October 2018, and I had to do it because of this bug. Was it a design issue in VMware? In macOS? In both? Were there bugs that have been fixed since on Apple’s side? Or VMware’s? Both? Honestly, who knows.

It does seem that I don’t run into this any longer. But there could be any number of reasons.

It seems Apple holds a dogmatic point of view (or used to?) of “well, applications shouldn’t be behaving this way”, but then sometimes they do, and when it leads to dataloss, that’s a bit of a bummer, to say the least.

Also sometimes if I go to About This Mac, and click on the Storage tab, it gives what appears to be a more accurate assessment of my free space vs the Finder.

I recommend using something like DaisyDisk instead.

Finder definitely overcounts “available” — some stuff it counts as “available” isn’t actually free on the volume, but can be made free by purging. And macOS is supposed to do that automatically. I’m guessing that part doesn’t always work right.

@Adrian With an adapter it should be possible to use standard NVMe SSDs. You may have to disable "safe sleep" for it to work correctly though, search on forums for compatibility.

I wonder if it is possible to delete the old snapshot with csrutil authenticated-root disable

Adding to what Brendan said, this thread at MacRumors is the best source I've seen for all information about upgrading SSD:s in older MBP.

Hey wow, that MacRumours page is fantastic, thanks so much for that. Thanks to the others for the extra info too, I really appreciate it, you all probably saved me from buying a piece of junk from eBay... 😬

The OWC drives look like the most sensible choice... but here in the UK they have a really steep premium -- they're 2.5x the price of very decent looking M.2 NVMe drives. I think I'll try the M.2 + adapter route, and if it doesn't work out find another use for the drive and go for a smaller drive from OWC.

Thanks again :)

Update: having read some of that massive MacRumours post I think I've changed my mind. I'm leaning towards a second-hand genuine Apple/Samsung SSD now...

M.2 NVMe + adapter seems almost perfect, and I love the prices, but there are two major downsides -- sleep mode/hibernate might not work, and it might draw more power (the MacRumours info suggests that's because the CPU will run 10-15C warmer, which sounds a lot to me). And since I almost never shutdown/reboot my laptop (just for updates), any sleep/hibernate issues would drive me mad...

No perfect answers. I'll try and find a good second hand option from a seller with a high positive-feedback number and see what happens...

Adrian O'Connor

Last update: My cheap-ish second-hand Apple SSD (4x PCIe) arrived today and I now have enough space to run Xcode 12 beta and Big Sur. I went for 250GB because 500GB was a bit too much money to take the risk, so I'll be running out of space again at some point -- but not like before, 128GB was just crazy difficult to live with and I spent way too much time trying to free up space to do things like update Xcode.

The guy I bought it from had packaged this drive in an empty box from a 1TB M.2 drive, which figures. Maybe one day I'll get brave enough to try it myself...

Well its full release much the same. Bought a 500GB pro for the space for development tools (Xcode 12 took FOREVER to install and even then i couldn't use the app store to install it). Had 400GB of free space before big sur, now its slowly depleting and i have 280GB left. Only way to stop it is to shut down my computer. On the phone with apple support for three hours couldn't provide help or answers. Hopefully they fix this shit soon.

May I ask a few questions about APFS boot volume on Released Big Sur (11.2.1)?

My internal drive (2TB) has only one APFS Container with four (4) APFS volumes on it.

  ⦁   Catalina (10.15.7) is installed on volumes "Macintosh HD" & "Macintosh HD - Data"

  ⦁   Big Sur (11.2.1) is installed on volumes "Mac SSD" & "Mac SSD - Data"

HOWEVER ... When BOOTED in Big Sur and I look at the drive via Disk Utility I see the following:

v Apple SSD
   v Container disk1
      v Mac SSD (grayed out)
         com.apple.os.update-CExxxxxxxxxxxxxxxxxx
      Mac SSD - Data
      Macintosh HD (grayed out)
      Macintosh HD - Data

When I run "diskutil list internal" I obtain the following output:

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *2.0 TB     disk0
   1:                        EFI ⁨EFI⁩                     314.6 MB   disk0s1
   2:                 Apple_APFS ⁨Container disk1⁩         2.0 TB     disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +2.0 TB     disk1
                                 Physical Store disk0s2
   1:                APFS Volume ⁨Macintosh HD - Data⁩     1.6 TB     disk1s1
   2:                APFS Volume ⁨Preboot⁩                 407.8 MB   disk1s2
   3:                APFS Volume ⁨Recovery⁩                1.1 GB     disk1s3
   4:                APFS Volume ⁨VM⁩                      2.1 GB     disk1s4
   5:                APFS Volume ⁨Macintosh HD⁩            11.2 GB    disk1s5
   6:                APFS Volume ⁨Mac SSD - Data⁩          204.5 GB   disk1s6
   7:                APFS Volume ⁨Mac SSD⁩                 15.1 GB    disk1s7
   8:              APFS Snapshot ⁨com.apple.os.update-...⁩ 15.1 GB    disk1s7s1

QUESTIONS:

  ⦁   Is it correct that Mac SSD is grayed out?
  ⦁   What is the "Preboot" volume?
  ⦁   What is the "VM" volume?
  ⦁   Should both Catalina and Big Sur each have their own "Recovery" volume?
  ⦁   Is the one "Recovery" volume present for Big Sur or Catalina?
  ⦁   How can I tell which "Recovery" this is? Does it matter?

THANKS in advance for any insight anyone can provide!!

> ⦁ Is it correct that Mac SSD is grayed out?

I think so, though I'm not sure if this signifies that it's read-only, or that it's a system volume. (Both are true.)

> ⦁ What is the "Preboot" volume?

I believe this essentially contains the login screen. The actual OS cannot boot yet because the volume is encrypted, so what looks like the macOS login screen is actually a fake/mini version of macOS.

>⦁ What is the "VM" volume?

Virtual memory / "swap". On HFS+, this was placed in the regular volume; with APFS, it's a separate volume. The same is common on Linux.

>⦁ Should both Catalina and Big Sur each have their own "Recovery" volume?

No, I believe your configuration is correct.

> ⦁ How can I tell which "Recovery" this is?

Well, you could boot into it. :-) (If you're on an Intel Mac, you can do this by holding cmd-R on startup.)

> Does it matter?

Normally, it shouldn't — what should happen is that macOS Recovery is always the most current version. So in your case, it should be Big Sur. Updates to your most recent OS will also update Recovery.

However, the flip side of that is: if such an update fails or introduces a bug, now your only means of Recovery is buggy. This is of course particularly likely if you use beta versions of macOS.

While I'm not aware of such an incident, I am aware of something similar, regarding bridgeOS (that's the OS that runs things like the Touch Bar, and some T2 functionality): John Siracusa ran into a problem (with the system failing to wake up from sleep, I believe?), and first surmised that it must be a bug in the beta, but then saw it happening no Catalina as well. It took him a while to realize that the problem was bridgeOS-related, and that bridgeOS, too, gets updated in tandem with the most recent macOS. So having a beta OS on a separate partition actually affected reliability of the main OS.

TL;DR: again, yes, it technically does matter, but in most cases won't be a problem.

Leave a Comment