6

У меня есть несколько больших жестких дисков, отформатированных в exFAT для обеспечения чистой совместимости между Win7/Bootcamp и Snow Leopard.

Вот проблема: fsck_exfat требуется что-то вроде 6-8 ГБ ОЗУ для завершения на большом диске. (windows 'chkdsk работает нормально, кстати). Если OSX обнаруживает том как грязный, он автоматически пытается fsck тома ... но я обнаруживаю, что это на самом деле не решает никаких проблем. Во время этого автоматического сканирования OSX должен пейджировать почти все остальное для обмена. Я использую несколько внешних накопителей, когда я нахожусь дома за столом, и если том exFAT загрязнен, то может пройти 10+ минут, прежде чем ноутбук можно будет использовать для каждого накопителя, и это после загрузки Finder.

Прежде чем предлагать использовать альтернативную файловую систему:

  • FAT32 - ограничение файла 4 ГБ - проблема для меня, и у меня есть по крайней мере один диск 3 ТБ. Рассматривая форматирование назад для меньших дисков
  • NTFS - каждый драйвер OSX NTFS, который я пробовал, отстой. ntfs3g крайне неэффективен с использованием процессорного времени и по какой-то причине часто останавливает всю систему на несколько секунд за раз во время интенсивного ввода-вывода. Tuxera NTFS лучше, но все же дрянной для интенсивного использования. Такие вещи, как Finder, генерирующий миниатюры для большой папки изображений, или базовое использование Songbird в управляемой библиотеке размером более 300 Гб, становятся крайне неприятными (и шаткими).
  • HFS+ - Драйвер HFS, который я использую в Windows (Paragon в комплекте с диском Seagate), повредил хотя бы одну важную папку, и я отказываюсь к ней снова

Хуже того, я пытался запустить этот ноутбук без подкачки, так как меня раздражает поведение подкачки в OSX (в основном, это переносит неактивные данные на диск независимо от доступной оперативной памяти). Увеличение производительности от отключения файла подкачки было очень хорошим. НО! Когда fsck запускается автоматически, ноутбук вскоре после этого зависает из-за нехватки ОЗУ.

Это, конечно, привело меня в замешательство: запустить ноутбук, OSX видит грязный exFAT, автоматически fsck их из строя , ноутбук зависает, диски помечаются грязными из-за плохого выключения, пены, полоскания, повторения ... не приятно. Загрузка в Win7 и запуск chkdsk (и чистое завершение работы) выходит из этого цикла. Своп пока включен заново :-(

Самое приятное то, что мне все еще приходится вручную исправлять грязные тома, потому что по какой-то причине они монтируются только для чтения! Я могу только отменить это после того, как я сам fsck их!

Это очень расстраивает. Итак ... как отключить автоматический fsck_exfat который работает на грязном монтировании exFAT? Или у вас есть альтернативные решения? Я не возражаю против монтирования RO в OSX, если это означает, что я сохраняю контроль над своим компьютером (и могу fsck диски).

1 ответ1

1

Отказ от ответственности: у меня нет способа проверить это должным образом, но следующее может дать вам некоторый успех.

  • Отключить SIP: https://stackoverflow.com/a/32910408/619961
  • sudo plutil -replace FSPersonalities.ExFAT.FSRepairExecutable -string "/usr/bin/true" /System/Library/Filesystems/exfat.fs/Contents/Info.plist
  • Включить SIP

Фоновая идея . После поиска в коде ядра XNU полезных ссылок о том, как Apple могла реализовать эту функцию, и анализа двоичного файла exfat_mount в бункере, я предположил, что замена либо FSRepairExecutable либо FSVerificationExecutable для простого всегда успешного возврата может решить вашу проблему.

Вот соответствующая часть соответствующего списка ExFAT:

  "FSPersonalities" => {
    "ExFAT" => {
      "FSRepairArguments" => "-y"
      "FSVerificationArguments" => "-n"
      "FSFormatMinimumSize" => 1048576
      "FSFormatExecutable" => "newfs_exfat"
      "FSFormatContentMask" => "Windows_NTFS"
      "FSName" => "ExFAT"
      "FSRepairExecutable" => "fsck_exfat"
      "FSMountExecutable" => "mount_exfat"
      "FSMountArguments" => ""
      "FSVerificationExecutable" => "fsck_exfat"
      "FSXMLOutputArgument" => "-x"
      "FSFormatArguments" => ""
      "FSFormatMaximumSize" => 144115188075855872
    }
  }

Поскольку этот файл находится в папке /System , более новые ядра OSX защищают его с помощью SIP. Отсюда крошечный утомительный обходной путь, описанный выше.

В качестве альтернативы, чтобы упростить последующее редактирование этого plist-файла без существенного ущерба для вашей безопасности, вы также можете оставить SIP включенным, отключив его для части файловой системы в режиме восстановления:

   csrutil enable --without fs

Учитывая, что вы, похоже, в определенной степени боролись со своей проблемой, вы когда-нибудь задумывались о переходе на решение для виртуализации, такое как Parallels или VMWare?

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .