BTRFS 스냅샷에 nodatacow가 미치는 영향

BTRFS 스냅샷에 nodatacow가 미치는 영향

너무 많은 읽기/쓰기 작업을 수행할 때 문제가 있는 것으로 알려진 SD 카드를 실행하는 Raspberry Pi 4에서 BTRFS와 함께 Manjaro ARM을 실행하고 있습니다.

이러한 이유로 나는 라이브 스냅샷의 가능성을 희생하지 않고 이러한 작업을 피하고 싶습니다. 이것이 제가 BTRFS를 실행하여 이러한 스냅샷을 다른 곳에 백업할 수 있는 유일한 이유입니다.

저는 최근에 nodatacow 마운트 옵션을 사용하여 BTRFS 하위 볼륨을 마운트할 때 스냅샷을 가질 수 있다는 사실을 발견했습니다 .1] [2] , COW를 비활성화합니다. 또한 기술적인 이유로 이 옵션이 시스템 전체에 제공되어야 한다는 것도 알고 있습니다 .] .

제가 이해한 바에 따르면 COW를 비활성화하면 메타데이터를 예상하는 "정상적인" 파일 시스템 동작이 수행됩니다 .4] , 이는 새로 쓸 때 파일 내용을 항상 덮어쓰게 됨을 의미합니다. 그러나 내 경험에 의하면 [2] , 후속 쓰기를 위해 새 위치를 할당하면서 각 파일의 현재 버전을 저장하는 스냅샷을 수행한다면 이는 본질적으로 nodatacow이며 새 쓰기를 덮어쓰게 됩니다. 즉, 현재 버전과 스냅샷(이는 두 가지 버전 시스템만 갖게 됩니다. 정상적으로 쉽게 복원될 수 있습니다.)

또 다른 단점은 체크섬 및 압축을 비활성화하는 것입니다 .] .

현재 문제를 올바르게 이해하고 있습니까?

nodatacow 마운트 옵션을 사용하면 파일 시스템과 스냅샷 크기, 조각화 및 성능(IO 작업)에 어떤 영향을 미치나요?

답변1

btrfs와 관련 없는 것을 조사하는 동안 이 문제를 발견했습니다. 귀하의 질문 중 일부에 답변해 드릴 수 있을 것 같습니다.

Nodatacow는 SD 카드의 실제 조각화 및 성능에 어떤 영향을 줍니까?

별로. 그 이유는 합리적인 쓰기 크기(삭제 블록 크기에 최대한 가깝게)가 주어지면 fs 수준 COW가 그렇지 않으면 발생하는 블록 장치 수준 COW를 대체하기 때문입니다.

물론 중요한 것은 SD 카드의 실제 삭제 블록 크기를 아는 것입니다. 그러나 파일 시스템 블록 크기가 미디어의 지우기 블록 크기보다 작더라도(이런 경우가 종종 있음) 꽤 좋은 성능을 얻을 수 있습니다.

블록 장치 수준 COW/동적 마모 평준화(SD 카드의 컨트롤러 칩에 의해 수행됨)와 fs 수준 COW 모두 조각화를 생성할 수 있지만 이는 탐색 시간이 부족하기 때문에 일반적으로 SD 카드 및 SSD의 문제로 간주되지 않습니다. .

제자리에 쓰기에 지우기 블록 크기가 중요한 이유는 무엇입니까?

Raspi 포럼에서:https://forums.raspberrypi.com/viewtopic.php?t=11258

보시다시피, 삭제 블록 크기는 매우 클 수 있습니다(최대 16개).중간 사이즈이 스레드의 예에서). 이는 SD 카드에 내부/nocow 쓰기를 수행할 때 카드가 16M을 지운 다음 최대 16M을 써야 할 수 있음을 의미합니다.아무리 많은 데이터를 써도. 그러나 이는 최악의 시나리오일 뿐입니다. 이는 SD 카드 및 SSD의 컨트롤러가 마모 평준화를 돕기 위해 자체 버전의 COW를 수행하려고 시도하기 때문에 발생합니다. 즉, 기록하는 블록을 상대적으로 거의 사용되지 않는 플래시 미디어에 다시 매핑하고 이전에 지워진 블록을 다시 매핑하기 때문입니다.

nodatacow로 인해 디스크 크기는 어떻게 변경되나요?

다시 말하지만 많지는 않습니다. 어떤 경우든 btrfs 삭제는 비동기식으로 수행됩니다. 즉, 파일을 삭제한다고 해서 디스크 공간을 즉시 다른 용도로 사용할 수 있는 것은 아닙니다. 대신, 또 다른 프로세스는 파일 시스템(일반 볼륨, 스냅샷 등)에서 데이터가 얼마나 자주 참조되는지 확인하고 개수가 0에 도달하면 제거하는 것입니다. 이는 datacow와 nodatacow도 마찬가지입니다. 눈에 띄는 유일한 차이점은 쓰기 작업이 매우 바쁜 비스냅샷 파일이 있는 동시에 남은 여유 공간을 확인하는 경우입니다. 디스크 공간이 올바른 값에 도달하는 데 더 많은 지연이 발생할 수 있습니다. 위협적이고 사용량이 많은 파일은 실제로 포함된 것보다 일시적으로 더 많은 미디어 공간을 사용할 수 있습니다.

내가 뭘 추천해?

불필요한 쓰기를 최소화하려면 마운트 옵션을 사용하고 noatime, 파티션이 쓰기 블록 크기와 올바르게 정렬되어 있는지 확인하고, 쓰기 증폭을 방지하기 위해 삭제 블록 크기와도 정렬하는 것이 더 좋을 것입니다. 그런 다음 한 번 시도하십시오. SSD 및 플래시 미디어에 대한 다른 모든 최적화는 상당히 표준적인 파일 시스템을 사용하는 경우 거의 필요하지 않습니다(사용량이 많은 데이터베이스 및 가상 머신 이미지 제외).

관련 정보