☰

如何在不重新格式化磁盘的情况下解决卷“VM”的 APFS 过度分配错误

tag-icon • tag-icon hard-drive virtual-memory apfs
如何在不重新格式化磁盘的情况下解决卷“VM”的 APFS 过度分配错误

我在驱动器的 APFS 容器上运行了“磁盘实用程序急救”。其中一个卷（称为“VM”）发出以下警告：

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

我还运行了diskutil verifyVolume /dev/disk1s4，其中disk1s4是与“VM”卷对应的标识符。这没有返回警告。考虑到这一点，并且知道 VM 卷的用途，我认为这种情况不是问题，而是verifyVolume在整个容器上运行的结果。

也就是说，由于 VM 卷用于在卷之间进行交换，因此它可能在验证容器的过程中使用，这就是它返回过度分配警告的原因。但这只是我的猜测。

这一个线程说重新格式化驱动器是他们的解决方案。但是，我昨天刚刚重新格式化了我的驱动器，不得不等待 12 个小时（我计时）才能从 Time Machine 恢复所有 700 多 GB。该线程有许多其他系统文件问题，所以我希望我的情况不必诉诸从头开始这样激烈的措施。

我很欣赏您的见解。

PS：如果你想知道 VM 卷的用途，这里是一个链接。
PPS：我宁愿在 SO 中发布此内容，因为该网站对关键字搜索“分配”的点击率更高。但我却被发到了这里。

答案1

因此我做了一些实验，看来问题可能确实只是尝试验证 APFS 容器而不是它的某个卷的结果，至少当您检查的是系统卷时。

在典型设置中，您的输出diskutil可能看起来像这样：

/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

在这种情况下，验证容器（diskutil verifyVolume disk0s2）似乎是应该工作，但即使在新格式化的磁盘上，它也会导致奇怪的错误，这些错误在再次检查时不会发生，或者从恢复或另一个启动磁盘检查时不会发生。

然而有趣的是，在处理第二个（非系统）APFS 驱动器时，验证容器本身似乎没问题，例如如果布局如下所示：

/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

在这种情况下，验证容器与验证其中的唯一卷在功能上是等效的。

我不知道为什么会有差异。不管是什么原因，至少对于检查系统卷来说，最好只检查特定的卷，如下所示：

diskutil verifyDisk disk0
diskutil verifyVolume disk1s1

从理论上讲，APFS 应该比 HFS+ 更能抵御损坏，因为现在所有元数据都应该被校验和。

话虽如此，我的系统卷在 APFS 下出现过问题，但这是由于断电造成的，导致快照处于损坏状态（无法使用tmutil或删除它diskutil apfs deleteSnapshot，需要完全擦除才能修复）。我进行检查主要是出于担心，以防这种情况再次发生（新fsck_apfs版本可能也能修复此类问题，我不确定）。

相关内容