btrfs는 파일 조각 모음도 균형을 유지합니까?


9

내가 실행할 때 btrfs filesystem balance파일을 암시 적으로 조각 모음합니까? 균형은 단순히 기존 조각화를 유지하면서 각 파일 범위를 개별적으로 재 할당한다고 상상할 수 있습니다.

''밸런스 '의 기능은 무엇입니까?' 라는 FAQ 항목이 있습니다. 이 시점에서 명확하지 않습니다.

btrfs 파일 시스템 밸런스는 파일 시스템의 모든 데이터와 메타 데이터를 단순히 가져 와서 디스크의 다른 위치에 다시 작성하여 할당 자 알고리즘을 통해 전달하는 작업입니다. 원래는 다중 장치 파일 시스템 용으로 설계되어 여러 장치에 데이터를보다 균등하게 분산시킵니다 (즉, 사용량을 "균형"으로 조정). 이는 거의 전체 파일 시스템에 새 장치를 추가 할 때 특히 유용합니다.

균형이 작동하는 방식으로 인해 몇 가지 유용한 부작용이 있습니다.

  • 할당되었지만 사용하지 않은 데이터 또는 메타 데이터 청크가 많으면, 할당 된 공간 중 일부가 저울에서 회수 될 수 있습니다. 이것이 단일 장치 파일 시스템에서 저울을 실행하는 주된 이유입니다.
  • 복제가 손상된 파일 시스템 (예 : 디스크가 손상되고 제거 된 RAID-1 FS)에서 FS는 현재 활성 장치 중 하나에서 누락 된 데이터 복사본을 다시 작성하여 시스템의 RAID-1 기능을 복원합니다. 파일 시스템.

답변:


10

TL; DR

Btrfs의 조각 모음 기능은 폴더 메타 데이터 및 파일 내용의 조각화를 수정하는 데 고유 한 반면, 균형 기능은 드라이브를 추가하거나 제거 할 때마다 드라이브간에 공유되는 데이터의 양 을 " 밸런스 "(이름)하기 위해 만들어졌습니다 . 그것들은 그들이하는 것과 이론적으로 겹치는 부분이 있지만, 그것들은 직접적으로 관련이 없기 때문에 문서는 두 기능을 연결하지 않습니다.

자세한 답변은 아래를 참조하십시오. 물론 저의 긴 대답은 직면 한 문제에 대한 완전한 맥락을 갖지 못하는 다른 사람들을 도울 것이라는 희망에 있습니다.


청크 할당

btrfs의 중요한 개념은 청크 할당입니다. 당신이 btrfs를 데이터를 쓸 때, 1GB의 크기는 일반적으로 "현재"덩어리로 데이터를 기록 1 . "현재"청크가 가득 차면 새 청크를 할당합니다. 기존 청크를 비우면 새 청크가 필요할 때 저장 공간을 다시 할당 할 수 있습니다.

파일 시스템이 "dup", "single"또는 "raid1" 스토리지 프로파일 과 함께 둘 이상의 드라이브를 사용하는 경우, 청크 할당자는 항상 사용 가능한 여유 공간이 가장 큰 드라이브에 다음 새 청크를 배치하는 것을 선호합니다. 이렇게하면 일반적으로 드라이브가 동일하게 사용됩니다.


균형은 무엇을 하는가

밸런스 기능은 기존 데이터 청크를 가져 와서 "현재"청크에 다시 써서 작동합니다. 기존 청크를 이런 방식으로 비우면 할당자가 자동으로 사용할 수있게됩니다. 비어있는 기존 청크가 시작하기에 꽉 차 있지 않은 경우 (청크의 오래된 데이터가 삭제되었을 수 있음) 새로운 청크가 관련 데이터로 "보다 꽉 채워져"있기 때문에 디스크 공간이 확보됩니다.

이론적으로 이것은 조각 모음 전략의 일부로 사용될 수있는 부분으로, 많은 사람들이 이미 그렇게 생각한다고 생각합니다. 그러나 균형 기능은 특정 목적을 염두에두고 구축되었으므로 파일 내용을 보지 않는 이유는 무엇입니까 ? 그것은 단지 검사 데이터 여부는 기존의 덩어리 밖으로 복용하는 것은 관련 새로운 덩어리로 데이터를 복사하기 전에.

잔액 부분은 어디에 있습니까 ?

파일 시스템에 새 드라이브를 추가 할 때 할당자는 처음에 모든 새 데이터를 새 드라이브에 쓰는 경향이 있습니다. 주로 기존 드라이브보다 사용 가능한 공간이 더 많기 때문입니다. 모든 청크를 다시 쓰면 초기에 균형 잡힌 모든 청크가 새 드라이브에만 기록됩니다. 일단 균등화되면 (균형 균형 조정) 나머지 데이터는 드라이브간에 동일하게 재 할당됩니다.

전형적인 균형 시나리오 :

각각 240GB를 사용하는 2 개의 500GB 드라이브가 있습니다. 다른 500GB 드라이브를 추가합니다. 나는 일반적으로 :

  • 드라이브 a : 240GB 사용
  • 드라이브 b : 240GB 사용
  • 드라이브 c : 0GB 사용

모든 데이터의 균형을 시작합니다. 잔액을 통해 약 1/4 분기에 다음과 유사한 상황이 나타날 수 있습니다.

  • 드라이브 a : 180GB 사용
  • 드라이브 b : 180GB 사용
  • 드라이브 c : 120GB 사용

1/3 정도 쯤되면 균형이 잡힌 것으로 보입니다.

  • 드라이브 : 160GB 사용
  • 드라이브 b : 160GB 사용
  • 드라이브 c : 160GB 사용

물론이 시점에서 밸런스 작업을 중단 할 수는 있지만, 완료하려는 이유는 (좋고 나쁨) 3 입니다.


btrfs에서 조각화가 발생하는 방법

BTRFS는 소입니다 ( 복사 쓰기에 ) 파일 시스템, 데이터가 없다는 것을 의미 결코 이상 작성 (4) . 기존 100MB 파일이 있고 파일의 1MB 부분을 덮어 쓰면 해당 1MB 부분이 드라이브의 기존 데이터 위에 기록되지 않습니다. 대신 "현재"청크의 다른 곳에 작성됩니다. Btrfs는 새 데이터의 "조각"이 저장된 위치를 추적합니다. 이전 데이터가 기본적으로 유지된다는 의미이므로 데이터의 스냅 샷을 유지하는 데 가장 유용합니다. SSD는 매우 유사한 방식으로 데이터를 덮어 쓰지 않기 때문에이 CoW 메커니즘은 SSD의 수명과 성능을 유지하는 데 적합합니다.

조각 모음이 나오는 곳

장점에 관계없이 일부 파일은 매우 자주 덮어 쓰여 지므로 (일반적으로 데이터베이스 파일) 수백 개의 조각이 생깁니다. SSD를 사용하면 단기적으로 성능 저하가 거의 없습니다. 그러나 스핀들 드라이브의 경우 성능이 저하됩니다.

물론 한 가지 해결책은 btrfs의 조각 모음 기능을 사용하는 것입니다. 조각 모음 작업은 현재 청크의 파일 내용을 현재 상태의 논리적 순서로 다시 작성하여 조각을 수많은 개별 조각 대신 하나의 큰 100MB 데이터 집합으로 줄입니다.

다른 해결책은 이와 같은 파일에 "nocow"기능을 사용하는 것입니다. nocow 기능은 파일을 덮어 씁니다. nocow 5 6에 대한 경고 사항이 있습니다 .


다시 요약

  • 저울은 청크와 줄무늬를보고 실제로 해당 청크의 데이터가 관련이 있는지 여부를 제외하고 파일 내용을 인식하지 못합니다.

  • 조각 모음 작업은 폴더 데이터와 개별 파일 내용을보고 가능한 한 연속적인 방식으로 데이터를 다시 씁니다. 단점은 조각 모음으로 인해 중복 및 추가 드라이브 사용이 발생하는 스냅 샷입니다.


노트:

  1. 청크의 크기는 일반적으로 1GB이지만 크거나 작을 수 있습니다. RAID 유형을 사용하는 경우 일반적으로 청크는 여러 드라이브에서 1GB 배수로 스트라이프됩니다. 예를 들어, raid0이있는 5 개의 드라이브는 일반적으로 각 드라이브에 1GB 청크로 구성된 5GB 스트라이프가 생성됩니다.

  2. Btrfs는 "참조"를 사용하여 컨텐츠를 파일 화합니다. 파일의 일부를 덮어 쓰면 라이브 파일 시스템은 해당 데이터가 작성된 위치를 "참조"합니다. 그러나 스냅 샷은 여전히 ​​이전 위치를 "참조"할 수 있습니다. 스냅 샷이 없거나 이전 스냅 샷이 삭제되면 원래 덮어 쓴 내용을 나타내는 "ref"가 남지 않습니다. 그런 다음이 내용은 관련이없는 것으로 간주되며 잔액 작업에서 다른 관련 데이터와 함께 복사되지 않습니다.

  3. 이 시점에서 스토리지가 간단한 "단일"프로파일 7을 사용한다고 가정 하면 첫 번째 160GB 밸런스가 모두 새 드라이브로 이동하지만이 시점에서 여전히 약 320GB의 밸런스가 남습니다. 나머지는 드라이브에서 균등하게 균형을 이룰 것입니다. 스핀들을 사용하면 이상적으로는 데이터를 더 잘 "확산"하기 위해 btrfs가 3 개의 드라이브를 모두 재조정하기 전에 160 청크의 균형을 유지하는 것이 좋습니다. SSD를 통해 데이터의도 "확산"을 유지하기 위해 시도하는 것은 매우 훨씬 더 가능성이 가능성이 무의미 복잡하고, 도착 매우 SSD의 수명에 좋지.

  4. "nocow"기능은 예외입니다.

  5. 스냅 샷이있는 경우 "라이브"파일 조각 모음을 수행하면 스냅 샷과 "라이브"파일이 디스크의 다양한 데이터 위치를 참조하여 데이터가 복제되어 추가 디스크 공간을 차지합니다. 범용 중복 제거 기능을 사용할 수있게되면 문제가되지 않습니다.

  6. nocow를 사용하면 btrfs가 파일 내용에 대한 체크섬을 유지하지 않습니다.

  7. 대부분의 공격대 유형 (raid1은 예외)에서, 일반적으로 스트라이프는 모든 드라이브에 걸쳐 기록되므로 드라이브에서 "스프레드"는 무시됩니다 .


와우, 좋은 대답입니다. ZTR과 달리 책 등에서 BTRFS 사용자 관련 정보가 심각하게 부족하여 평판이 계속 나 빠지고 있음을 알 수 있습니다. 블로그 나 이와 같은 좋은 자료가 있습니까?
Andrew Keech

1
감사! 실제로 최신 콘텐츠를 가져와야합니다. :-| 시간이 너무
zaTricky

6

어쩌면보고 명령의 소스 코드 힘 도움말

취하다 btrfs balance start

'btrfs filesystem balance'명령은 더 이상 사용되지 않습니다. 대신 'btrfs balance start'명령을 사용하십시오.

그런 다음 명령 문자열에서

"btrfs [filesystem] balance start [options] <path>",
"Balance chunks across the devices",
"Balance and/or convert (change allocation profile of) chunks that",
"passed all filters in a comma-separated list of filters for a",
"particular chunk type.  If filter list is not given balance all",
"chunks of that type.  In case none of the -d, -m or -s options is",
"given balance all chunks in a filesystem."

두 번째 모양을 줄 수도 있지만 구조체 또는 ioctl () 호출에서 조각 모음에 대한 참조를 볼 수 없습니다. 따라서 명시적인 조각 모음이 없습니다.

한 장소에서 다른 장소로 복사하고 프로세스에서 기본 할당자를 사용하기 만하면됩니다. 여기에서 찍은

목적 할당 및 할당 모드에 따라, 알고리즘은 각각의 적절한 할당 그룹 (btrfs의 그룹은 전술 한 청크에 대응한다)에서 연속적인 여유 공간을 직접 검색한다

따라서 할당 모드, 장치의 여유 공간 등에 따라 btrfs가 조각 모음이 필요하지 않은 방식으로 할당된다고 말할 수 있습니다. 암시 적 조각 모음의 형태를 고려할 수 있습니다.

HTH


3

균형은 청크 수준에서 작동합니다. 청크는 Btrfs가 레이드 리던던시를 구현하는 방법입니다. Btree 수준에서는 아무런 작업도 수행하지 않으며 조각 모음이 수행되지 않습니다.


0

액세스 대기 시간이 긴 미디어를 사용하는 경우 사용 된 파일 시스템에 관계없이 항상 framentation이 계산됩니다. 탐색은 탐색을 유지합니다.


3
SSD 드라이브에서 데이터에 액세스하지 않는 한 전혀 의미가 없습니다.
Matt

1
그것은 질문에 대답하지 않습니다.
Karl Richter

-2

조각 모음이 과대 평가되었습니다. 물론, FAT16에서는 대부분의 경우 현대적인 것이 아니라 실질적인 차이를 만듭니다. 효과적으로, 재조정은 파일 시스템의 구성을 향상시키고 파일의 조각화가 줄어 듭니다.


6
조각화는 실제로 ext2 / 3 / 4, xfs, jfs 등의 문제는 아니지만 btrfs의 경우 심각한 문제가 될 수 있습니다. btrfs.wiki.kernel.org/index.php/Gotchas 를 참조하십시오. "무작위 쓰기가 많은 파일은 크게 조각화되어 (10000+ 범위) HDD에서 휴지통이 발생하고 시스템에서 CPU로드가 지나치게 많이 급증 할 수 있습니다. SSD 또는 많은 양의 RAM. " 일반적인 사용 사례 (비트 토렌트, sqlite 데이터베이스 등으로 다운로드 한 파일)의 경우에도 과장은 아닙니다.
nemequ

2
조각 모음은 특히 최신 드라이브에서 드라이브가 가득 차기 시작하면 더 현대적인 파일 시스템에서도 큰 차이를 만들 수 있습니다. 일부 파일 시스템은 다른 파일 시스템보다 파일 시스템을 더 잘 처리하고 일부 파일 유형은 다른 파일 시스템보다 더 나쁩니다. 여유 공간, 시나리오를 최적화 할 수 없음, 읽기 / 쓰기 캐시, 미리 읽기, 응용 프로그램 최적화 등으로 인해 많은 부분이 숨겨지는 경향이 있습니다. 대부분의 경우 사람들은 걱정할 필요가 없으며 실제로 조각화로 인해 심각한 문제가 있는지 걱정해야합니다.
jgmjgm
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.