Как устранить ошибку перераспределения APFS с тома "ВМ" без переформатирования диска
Я запустил Первую помощь Дисковой утилиты в контейнере APFS моего диска. Один из томов, называемый "VM", выдает следующее предупреждение:
warning: Overallocation Detected on Main device: (26707978+1) bitmap address (3bc0d)
РЕДАКТИРОВАТЬ: Итак, после того, как я опубликовал это, я побежал diskutil verifyVolume /dev/disk1s4, где disk1s4 является идентификатором, который соответствует тому "VM". Это не вернуло предупреждение. Имея это в виду и зная, для чего нужен том виртуальной машины, я полагаю, что этот случай не проблема, а следствие запуска verifyVolume на весь контейнер. То есть, поскольку том виртуальной машины используется для переключения между томами, он, вероятно, используется в процессе проверки контейнера, и поэтому он возвращает предупреждение о перераспределении. Но это только мое предположение. /РЕДАКТИРОВАТЬ
Этот поток говорит, что переформатирование диска было их решением. Однако вчера я просто переформатировал накопитель, и мне пришлось ждать изнурительных 12 часов (я рассчитал время), чтобы восстановить все более 700 ГБ с Time Machine. В этом потоке было много других проблем с системными файлами, поэтому я надеюсь, что в моем случае не придется прибегать к чему-то столь радикальному, как начало с нуля.
Я ценю ваши идеи.
PS: Если вам интересно, для чего нужен виртуальный том, вот ссылка.
PPS: Я бы предпочел опубликовать это в SO, потому что у этого сайта больше хитов по ключевому слову "распределение". Но вместо этого меня отправили сюда.
0 ответов
Поэтому я немного поэкспериментировал, и кажется, что проблема действительно может быть связана с попыткой проверить контейнер 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 версии также могут быть в состоянии исправить такие проблемы, я не уверен).