Mac users - any unaccounted 'used' disk space on your drives?

I’m not sure if this is a Big Sur issue or whether I’ve just noticed it, but on looking at my hard drive usage it says I have used 465.03 GB:

On that disk there is:

  • Applications (41.18 GB)
  • Library (2.89 GB)
  • System (24.89 GB)
  • Users (225.59 GB)

= 294.55 GB

…which leaves 170.48 GB unaccounted for.

I’ve looked at hidden files on the root level too, but they’re just 5 GB or so, so that still leaves 165 GB of disk space that seems to have vanished into thin air :rofl:

What’s the situation on your drive?

(You can select a folder/drive and press ‘CMD + I’ to show info (you can also select a number of folders and do the same.)

1 Like

What does a

$ diskutil list

give you?

1 Like

I’m not a mac user, though it says something about ~160GiB beeing purgeable.

How does it usually account for backups?

Also it seems as if APFS supports snapshots, how are those accounted?

As a ZFS user who uses snapshotting a lot in automated ways, I usually do not see the snapshots in a filemanager, but only by using the specialised ZFS tools.

Lets say du -sh ~ tells me that ~ were 230 GB, df -h ~ only says 209G due to compression, while a zfs list tells me this:

$ zfs list -o name,used,available,referenced,compressratio rpool/safe/home/nmelzer
NAME                      USED  AVAIL     REFER  RATIO
rpool/safe/home/nmelzer   302G  72.5G      209G  1.18x

As you can see, this subvolume refers to 209 G directly, while it has an overall size of 302G. The additional ~80G come from differences in the snapshots I keep for that volume.

Perhaps something similar is going on for your APFS?

1 Like

I get this:

~$ diskutil list
/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⁩     451.7 GB   disk1s1
   2:                APFS Volume ⁨Preboot⁩                 283.0 MB   disk1s2
   3:                APFS Volume ⁨Recovery⁩                652.6 MB   disk1s3
   4:                APFS Volume ⁨VM⁩                      20.5 KB    disk1s4
   5:                APFS Volume ⁨Macintosh HD⁩            14.9 GB    disk1s5
   6:              APFS Snapshot ⁨com.apple.os.update-...⁩ 14.9 GB    disk1s5s1

What are your drives showing you Ohm? Is it all accounted for?

I use external drives for Time Machine backups :smiley:

Looks like it could be that, although I wasn’t aware Apple were doing this (is it something like Windows ‘snapshots’? Been a while since I used Windows but remember them doing something like that.)

I have posted it as a bug with Apple… if I hear anything I will update this thread…

Windows “Snapshots” are totally different, they are just files copied from one location to another. Snapshots on the filesystem level are totally different from that, They mark blocks on your harddisk as immutable and will only change a copy of them and pretend the immutable copy has been overwritten, but still keep a reference to it.

You can then either drop those old references or roll back to them.

On BTRFS or ZFS I can create a snapshot worth 500 GiB of data in split seconds, and then copy this snapshot over to my backup system. And the nice thing is, the system can stay active in that time.

Lets consider a postgres or mysql database, usually if you just do a cp of the data folder and move use it as backup, then the database itself will probably be corrupted due to the serialised copy. eg. the index file has been copied after the table itself, and the index has been changed since then.

The snapshout of BTRFS and ZFS though is atomic. All files are fixed in time. If you snapshot and copy this snapshot as a backup, you can restart a database using that snapshot, and it will recover from it similar to how it would recover from a power outage, as all files still are coherent in their state.

1 Like

Thanks @NobbZ - looks like Apple are thinking it may be something to do with snapshots as well, they just got back to me asking for the outputs of:

diskutil apfs listSnapshots /System/Volumes/Data
diskutil apfs listSnapshots /

Which I’ve got:

~$ diskutil apfs listSnapshots /System/Volumes/Data
Snapshots for disk1s1 (6 found)
|
+-- D04A7C97-C49C-4E47-AB04-C21937338CA2
|   Name:        com.apple.TimeMachine.2020-11-16-221716.local
|   XID:         13467
|   Purgeable:   Yes
|
+-- 3C638701-2FE2-453E-86F2-971EC379C917
|   Name:        com.apple.TimeMachine.2020-11-17-021125.local
|   XID:         15506
|   Purgeable:   Yes
|
+-- C4E6AC14-5A84-43A4-92E0-5202F2096F4A
|   Name:        com.apple.TimeMachine.2020-11-17-031623.local
|   XID:         15921
|   Purgeable:   Yes
|
+-- 39CCC458-A519-4EC6-9E99-12EB5141FE84
|   Name:        com.apple.TimeMachine.2020-11-17-050950.local
|   XID:         16995
|   Purgeable:   Yes
|
+-- 9A1675D3-2E98-452D-AF13-E50B508A333E
|   Name:        com.apple.TimeMachine.2020-11-17-171828.local
|   XID:         18273
|   Purgeable:   Yes
|
+-- 7CB5C73F-5624-4A13-A433-663F4A7035D3
    Name:        com.apple.TimeMachine.2020-11-17-175339.local
    XID:         18632
    Purgeable:   Yes
    NOTE:        This snapshot limits the minimum size of APFS Container disk1
~$ 

and:

~$ diskutil apfs listSnapshots /
Snapshot for disk1s5s1 (1 found)
|
+-- 49BCE6EA-CDF8-4013-B50A-D2CAAA97FDEE
    Name:        com.apple.os.update-779BDF1556C6F688504E24FB29C75AFFABFCB91E701806FFFF35235E19914F1E
    XID:         268
    Purgeable:   No
    NOTE:        This snapshot limits the minimum size of APFS Container disk1
~$ 

So I wonder whether these are snapshots that are taken before they are transferred to my external HDs?