이 시나리오에서 btrfs nodatacow 마운트 옵션은 3개의 디스크에 어떤 영향을 줍니까?

이 시나리오에서 btrfs nodatacow 마운트 옵션은 3개의 디스크에 어떤 영향을 줍니까?

저는 BTRFS로 Arch Linux를 실행하고 있습니다. 이 컴퓨터에는 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에서 무슨 일이 일어나고 있습니까? nodatacow해당 옵션을 적용하여 하나의 디스크를 마운트합니까 ?세 개 모두내 물리적 디스크의? 아니면 각 디스크를 별도로 포맷하고 각 디스크에 BTRFS 파일 시스템을 만들었기 때문에 3개의 별도 파일 시스템이 있습니까?

관련 주제에서 nodatacow가 활성화되면 압축이 비활성화된다는 것을 이해합니다. compress=lzo이는 다음과 같이 세 번째 디스크를 마운트하기 위한 옵션을 제거해야 함을 의미한다고 가정합니다 .

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

가장 중요한 질문은 옵션을 사용하여 이 세 번째 디스크를 마운트하는 nodatacow것이 전체 파일 시스템(3개 디스크 모두와 아래의 모든 디렉터리 /)에 영향을 미치는지, 아니면 마운트 지점 아래의 파일 시스템(일부)에만 영향을 미치는지 여부입니다 /nocow.

사용하는 것이 좋을까요 chattr +C /nocow? 해당 속성이 나중에 해당 디렉토리에 마운트되는(그리고 nodatacow옵션 없이 마운트되는) 파일 시스템에 영향을 미치는지 확실하지 않기 때문에 그렇게 하지 않았습니다 .

/nocow일부 mysql 데이터베이스를 보유하고 있습니다.

답변1

나는 nodatacow가 파일 시스템 마운트 옵션이므로 사용 시 해당 파일 시스템의 마운트된 모든 하위 볼륨에 적용된다는 것을 이해합니다. 하지만 파일 시스템에 대한 명확한 정의가 없습니다. 때때로 파일 시스템은 여러 디스크에 걸쳐 있을 수 있습니다. 위의 fstab에서 무슨 일이 일어나고 있습니까?

세 가지 다른 UUID를 마운트하고 있으므로 실제로 세 가지 별도의 파일 시스템이 있다고 생각됩니다.

그러나 마운트에 하위 볼륨도 지정합니다. 이는 아마도 다음과 같은 레이아웃이 있음을 보여줍니다.

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

각각 하나의 하위 볼륨을 포함하는 세 개의 개별 파일 시스템이 있습니다. 이 경우 nodatacow마운트 옵션을 세 파일 시스템 각각에 개별적으로 적용할 수 있습니다.

그러나 btrfs하나의 파일 시스템(여러 HDD에 걸쳐 있을 수 있고 일부 RAID 형태를 사용할 수도 있지만 반드시 그런 것은 아님)만 가질 수 있으며 해당 파일 시스템의 별도 하위 볼륨(폴더와 유사)을 별도의 위치에 마운트할 수도 있습니다. 이는 다음과 같은 레이아웃이 있음을 의미합니다.

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

이 경우 nodatacow동일한 파일 시스템에 상주하는 모든 하위 볼륨에 마운트 옵션이 적용됩니다.

nodatacow로 하나의 디스크를 마운트하면 해당 옵션이 세 개의 실제 디스크 모두에 적용됩니까?

아니요.

아니면 각 디스크를 별도로 포맷하고 각 디스크에 BTRFS 파일 시스템을 만들었기 때문에 3개의 별도 파일 시스템이 있습니까?

예.

관련 주제에서 nodatacow가 활성화되면 압축이 비활성화된다는 것을 이해합니다.

이는 사실입니다[1]. /nocow 마운트에서 해당 마운트 옵션을 제거할 수 있습니다. 그러나 세 개의 별도 파일 시스템이 있으므로 원하는 경우 나머지 두 개(/ 및 /cow)는 여전히 압축을 활성화하여 마운트할 수 있습니다.

사용하는 것이 좋을까요 chattr +C /nocow?

nocow 작업을 달성하기 위해 이와 같은 확장된 파일 속성을 사용하는 것이 가능한 대안입니다.하지만:

  • chattr +C폴더가 아직 비어 있으면 폴더를 만들어야 합니다 !
  • 이미 있는 폴더에만 새 파일을 생성하거나 chattr +C먼저 touch해당 파일에 내용을 복사해야 합니다(자세한 내용은 [2] 참조).

nodatacow따라서 이미 수행한 것과 유사하게 마운트 옵션과 VM 또는 DB 파일에 대한 별도의 파일 시스템을 사용하는 것이 더 쉬울 수 있습니다 . (이 사용 사례에서는 Btrfs가 많은 이점을 갖지 않으므로 해당 파일 시스템에 대해 Btrfs를 사용할지 여부를 고려할 수 있습니다.)

일반적으로 btrfs에 VM 또는 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

[삼]https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation

관련 정보