How to resolve APFS overallocation error from volume "VM" without reformatting disk

Question

I ran Disk Utility's First Aid on my drive's APFS container. One of the volumes, called "VM", gives the following warning:

warning: Overallocation Detected on Main device: (26707978+1) bitmap address (3bc0d)

I also ran diskutil verifyVolume /dev/disk1s4, where disk1s4 is the identifier that corresponds to the "VM" volume. This did not return a warning. With that in mind, and knowing what the VM volume is for, I suppose this case is not a problem, but a consequence of running verifyVolume on the entire container.

That is, since the VM volume is used to swap between volumes, it is probably used during the process of verifying the container, and that's why it returns the overallocation warning. But that's just my speculation.

This one thread says that reformatting the drive was their solution. However, I just reformatted my drive yesterday and had to wait a grueling 12 hours (I timed it) to restore all 700+ GB from Time Machine. That thread had many other system file problems, so I hope my case won't have to resort to something as drastic as starting over from scratch.

I appreciate your insights.

PS: In case you're wondering what the VM volume is for, here is a link.
PPS: I'd rather post this in SO, because that site has more hits for the keyword search "allocation." But I got sent here instead.

Answer 1

So I did little experimenting and it seems the problem may indeed simply be a result of trying to verify the APFS container, rather than one of its volumes, at least when it's the system volume that you're checking.

In a typical setup your output from diskutil might look something like this:

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         1000.0 GB  disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +1000.0 GB  disk1
                                 Physical Store disk0s2
   1:                APFS Volume macOS                   74.9 GB    disk1s1
   2:                APFS Volume Preboot                 44.6 MB    disk1s2
   3:                APFS Volume Recovery                506.8 MB   disk1s3
   4:                APFS Volume VM                      20.5 KB    disk1s4

In this case verifying the container (diskutil verifyVolume disk0s2) seems like it should work, but even on a newly formatted disk it can result in odd errors, that then either don't occur when checked again, or don't occur when checking from recovery or another startup disk.

Interestingly however, verifying the container itself appears to be fine when dealing with a second (non-system) APFS drive, for example if the layout looks something like this:

/dev/disk0 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *4.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                 Apple_APFS Container disk3         4.0 TB     disk2s2

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +4.0 TB     disk3
                                 Physical Store disk2s2
   1:                APFS Volume Data                    2.67 TB    disk3s1

In such a case it seems verifying the container versus verifying the only volume in it, are functionally equivalent.

Why there should be a difference, I have no idea. Whatever the cause, it seems that for checking the system volume at least that it may be best to check only specific volumes, like so:

diskutil verifyDisk disk0
diskutil verifyVolume disk1s1

In theory APFS should be more resilient to corruption than HFS+ anyway, since all the metadata is supposed to be checksummed now.

That said, I have had a system volume go bad under APFS, but this was a result of a power loss, resulting in a snapshot being left in a broken state (couldn't remove it using tmutil or diskutil apfs deleteSnapshot, requiring a full erase to fix it). I run checks mostly out of paranoia to keep an eye out in case it ever happens again (newer fsck_apfs versions may also be able to fix such issues, I'm not sure).