web-dev-qa-db-ja.com

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

私はBTRFSでArchLinuxを実行しています。このコンピューターには3台の物理HDDがあります（RAIDなどはありません）。 /、/cow、/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でマウントすると、そのオプションが私の物理ディスクのつすべてに適用されますか？または、各ディスクを個別にフォーマットし、各ディスクにBTRFSファイルシステムを作成した場合、3つの個別のファイルシステムがありますか？

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

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

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

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

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

linuxfilesystemsmountbtrfs
2
MountainX

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マウントオプションは、同じファイルシステム上にあるため、すべてのサブボリュームに適用されます。

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

番号。

または、各ディスクを個別にフォーマットし、各ディスクにBTRFSファイルシステムを作成した場合、3つの個別のファイルシステムがありますか？

はい。

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

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

chattr +C /nocowを使用する方が良いでしょうか？

Nocow操作を実現するためにこのような拡張ファイル属性を使用することは可能な代替手段です だが：

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

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

一般に、VMまたはbtrfsにDBファイルを保存する場合は、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#Fragmentation

3
Erki der Loony