web-dev-qa-db-ja.com

MacOSXのダーティボリュームマウントで自動fsck_exfatを無効にする

Win7/BootcampとSnowLeopardの間のクリーンな互換性を維持するために、exFATでフォーマットされたいくつかの大容量ハードディスクがあります。

問題は次のとおりです。fsck_exfatは、大きなディスクで完了するために6〜8GBのRAM）のようなものが必要です（Windowsのchkdskは正常に動作します）。OSXがボリュームをダーティとして検出した場合、ボリュームを自動的にfsckしようとしているように見えます...しかし、実際には問題が修正されていないことがわかりました。この自動スキャン中に、OSXはほぼすべてをページングする必要があります自宅のデスクにいるときに複数の外付けドライブを使用していますが、exFATボリュームが汚れていると、ラップトップが使用可能になるまでに10分以上かかる場合がありますドライブごと後ファインダーがロードされます。

代替ファイルシステムの使用を提案する前に：

  • FAT32-4GBのファイル制限は私にとって問題であり、少なくとも1つの3TBドライブがあります。小さいドライブ用にこれにフォーマットし直すことを検討する
  • NTFS-私が試したすべてのOSXNTFSドライバーは最悪だ。 ntfs3gはCPU時間に対して非常に非効率的であり、何らかの理由で、大量のI/O中に一度に数秒間システム全体をフリーズさせることがよくあります。 Tuxera NTFSの方が優れていますが、それでも頻繁に使用するには安っぽいです。 Finderが画像の大きなフォルダのサムネイルを生成したり、300 GB以上のマネージドライブラリでSongbirdを基本的に使用したりすると、非常に不快になります（そして厄介になります）。
  • HFS + -Windowsで使用しているHFSドライバー（SeagateドライブにバンドルされているParagon）で、少なくとも1つの重要なフォルダーが破損しているため、再度触れることを拒否します

さらに悪いことに、OSXのスワップ動作に腹を立てているので、このラップトップをスワップなしで実行しようとしていました（基本的に、使用可能なRAMに関係なく、非アクティブなものをディスクにページングします）。スワップファイルを無効にすることによるパフォーマンスの向上は非常に良かったです。だが！ fsckが開始するたびに、自動的に、RAMが不足するため、ラップトップはその後すぐにフリーズします。

もちろん、これは私をループに陥らせました：ラップトップを起動すると、OSXは汚れたexFATを認識し、自動的にfscksし、ラップトップがフリーズし、シャットダウンが悪いためにドライブが汚れたとマークされ、泡立ち、すすぎ、繰り返し...不快です。 Win7を起動してchkdskを実行する（そしてクリーンにシャットダウンする）と、このループから抜け出します。スワップは今のところ再び有効になっています:

最良の部分は私です---（まだ何らかの理由で読み取り専用としてマウントされるため、ダーティボリュームを手動で修正する必要があります！自分でfsckした後でないと、元に戻すことができません。

これは最も苛立たしいことです。では...ダーティなexFATマウントで実行される自動fsck_exfatを無効にするにはどうすればよいですか？または、代替ソリューションはありますか？ OSXがドライブをマウントすることを気にしませんROコンピュータの制御を維持することを意味する場合（そして後でドライブをfsckすることができます）。

macosfsckexfat
8
Tom Corelis

免責事項：正しくテストする方法はありませんが、次の方法である程度成功する可能性があります。

  • 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関連のplistの関連部分は次のとおりです。

  "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などの仮想化ソリューションに移行することを考えたことはありますか？

3
Moreaki

インスピレーション モレアキの答え （これはモハベでは機能しないようです）私はこの醜い回避策を思いつきました：

  1. SIP（Moreakiの回答を参照）を無効にします。
  2. 元のfsck_exfatのバックアップを作成します。
    Sudo cp /System/Library/Filesystems/exfat.fs/Contents/Resources/fsck_exfat /System/Library/Filesystems/exfat.fs/Contents/Resources/fsck_exfat_ORIGINAL
  1. fsck_exfatバイナリを/usr/bin/trueに置き換えます。
    Sudo cp /usr/bin/true /System/Library/Filesystems/exfat.fs/Contents/Resources/fsck_exfat
  1. SIPを有効にします。

注：which -a fsck_exfatは、/sbin/fsck_exfatの下の実際のバイナリへのシンボリックリンクである/System/Library/...にバイナリを表示します。 MacがExFatディスクをチェックしている間、fsck_exfatでps aux | grep exfatへの実際のパスを確認できます。

[〜＃〜]警告[〜＃〜]：この変更後、システムは自動チェックを行わず、 exfatドライブの修正はもうありません！これらのドライブのエラーをチェックして修正するには、WindowsやLinuxなど、より優れたexfatサポートを備えたOSを使用することをお勧めします。また、別のOSがない場合でも、手順2で作成したコピー（/System/Library/Filesystems/exfat.fs/Contents/Resources/fsck_exfat_ORIGINAL）を使用できます。このメソッドはダーティビットを削除しません—応答コード（fsck_exfat）が成功すると0から即座に戻るだけです。

1
ccpizza