☰

このシナリオでは、btrfs nodatacow マウント オプションは 3 つのディスクにどのような影響を与えますか?

tag-icon • tag-icon linux filesystems mount btrfs
このシナリオでは、btrfs nodatacow マウント オプションは 3 つのディスクにどのような影響を与えますか?

/私は BTRFS で Arch Linux を実行しています。このコンピュータには 3 つの物理 HDD があります (RAID などはありません)。 に1 台、 に 1 台/cow、 に 1 台マウントされたディスクがあります/nocow。これが fstab です:

# /etc/fstab
# <file system> <dir>   <type>  <options>       <dump>  <pass>
UUID=a101       /               btrfs           rw,noatime,nodiratime,compress=lzo,space_cache,subvol=/@ 0 0
UUID=b202       /cow            btrfs           rw,noatime,nodiratime,compress=lzo,space_cache,subvol=/@cow 0 0
UUID=c303       /nocow          btrfs           rw,noatime,nodiratime,compress=lzo,space_cache,nodatacow,subvol=/@nocow 0 0

それnodatacowはファイルシステムマウントオプションなので、そのファイルシステムのマウントされたすべてのサブボリュームに適用する、使用時に。しかし、ファイルシステムの明確な定義がありません。ファイルシステムが複数のディスクにまたがることもあります。上記のfstabで起こっているのはそれですか？1つのディスクをマウントすると、nodatacowそのオプションが適用されますか？3つすべて物理ディスクの？ または、各ディスクを個別にフォーマットし、各ディスクに BTRFS ファイルシステムを作成したため、3 つの個別のファイルシステムがあるのでしょうか？

関連するトピックとして、nodatacow を有効にすると圧縮が無効になることは理解しています。つまり、compress=lzo次のように 3 番目のディスクをマウントするためのオプションから削除する必要があると思います。

UUID=c303 /nocow btrfs rw,noatime,nodiratime,space_cache,nodatacow,subvol=/@nocow 0 0

最も重要な問題は、この 3 番目のディスクをnodatacowオプションでマウントすると、ファイルシステム全体 (3 つのディスクすべてと の下にあるすべてのディレクトリ/) に影響するのか、それともマウント ポイント の下にあるファイルシステム (の一部) だけに影響するのかということです/nocow。

を使用する方が良いでしょうかchattr +C /nocow? その属性が、後でそのディレクトリにマウントされる (オプションなしでマウントされる) ファイルシステムに影響するかどうかわからないため、私はそれを行いませんでしたnodatacow。

/nocowいくつかの MySQL データベースを保持します。

答え1

nodatacow はファイルシステムのマウント オプションであり、使用すると、そのファイルシステムのすべてのマウントされたサブボリュームに適用されることは理解しています。しかし、ファイルシステムの明確な定義がありません。場合によっては、ファイルシステムが複数のディスクにまたがることがあります。上記の fstab ではそれが起こっているのでしょうか?

3 つの異なる UUID をマウントしているので、実際には 3 つの別々のファイルシステムがあると思われます。

ただし、マウント時にサブボリュームも指定しています。これにより、おそらく次のレイアウトになっていることがわかります。

HDD1
└──── Filesystem 1 (a101)
      └──── Subvolume /@ mounted at /
HDD2
└──── Filesystem 2 (b202)
      └──── Subvolume /@cow mounted at /cow
HDD3
└──── Filesystem 3 (c303)
      └──── Subvolume /@nocow mounted at /nocow

3 つの個別のファイルシステムがあり、それぞれに 1 つのサブボリュームがあります。この場合、nodatacowマウント オプションは 3 つのファイルシステムのそれぞれに個別に適用できます。

ただしbtrfs、ファイルシステムを 1 つだけ (複数の HDD にまたがる可能性があり、何らかの形式の RAID を使用する可能性もありますが、必ずしもそうとは限りません) 使用し、その 1 つのファイルシステムの個別のサブボリューム (フォルダーに類似) を別の場所にマウントすることもできます。つまり、次のようなレイアウトになります。

HDD1 [...HDDn]
└──── Filesystem 1
      ├──── Subvolume /@ mounted at /
      ├──── Subvolume /@cow mounted at /cow
      └──── Subvolume /@nocow mounted at /nocow

その場合、nodatacowサブボリュームは同じファイルシステム上に存在するため、マウント オプションはすべてのサブボリュームに適用されます。

1 つのディスクを nodatacow でマウントすると、そのオプションが 3 つの物理ディスクすべてに適用されますか?

いいえ。

または、各ディスクを個別にフォーマットし、各ディスクに BTRFS ファイルシステムが作成されたため、3 つの個別のファイルシステムが存在することになりますか?

はい。

関連するトピックとして、nodatacow を有効にすると圧縮が無効になることを理解しています。

それは本当です[1]。/nocow マウントでそのマウント オプションを削除できます。ただし、3 つの別々のファイルシステムがあるため、必要に応じて他の 2 つ (/ と /cow) を圧縮を有効にしてマウントすることもできます。

を使用した方が良いでしょうかchattr +C /nocow?

このような拡張ファイル属性を使用してnocow操作を実現することも代替案として考えられます。しかし:

  • chattr +Cまだ空の場合は、フォルダーを削除する必要があります。
  • chattr +C既存のフォルダ内にのみ新しいファイルを作成するか、最初に新しいファイルを作成してからその内容をそのフォルダにコピーする必要がありますtouch（詳細は[2]を参照）。

したがって、すでに行ったのと同様に、マウント オプションと VM または DB ファイル用の別のファイルシステムを使用する方が簡単かもしれませんnodatacow。(このユース ケースでは Btrfs にはそれほど多くの利点がないため、そのファイルシステムに Btrfs を使用するかどうかを検討することもできます。)

一般的に、VMまたはDBファイルをbtrfsに保存する場合は、マウントオプションも含めることを検討してくださいautodefrag。そうしないと、ランダム書き込みが多い大きなVMまたはDBファイルがすぐに断片化され、パフォーマンスが低下する可能性があります[3]。

[1]https://btrfs.wiki.kernel.org/index.php/Compression#How_does_compression_interact_with_direct_IO_or_COW.3F

[2]https://btrfs.wiki.kernel.org/index.php/FAQ#Can_copy-on-write_be_turned_off_for_data_blocks.3F

[3]https://btrfs.wiki.kernel.org/index.php/Gotchas#断片化

関連情報