Btrfs

Btrfs
Btrfs
개발자Facebook, Fujitsu, Fusion-IO, Intel, Linux Foundation, Netgear, Oracle Corporation, Red Hat, STRATO AG 및 open수세[1]
풀네임B-트리 파일 시스템
소개했다Linux 커널 2.6.29, 2009년 3월, 13년 전(2009-03)
구조물들
디렉토리 내용B-트리
파일 할당익스텐트
한계
최대 볼륨 크기16 EiB[2][a]
최대 파일 크기16 EiB[2][a]
최대 파일 수2개64[b][3]
최대 파일 이름 길이255자의 ASCII 문자(Unicode 등의 멀티바이트 문자 인코딩의 경우 감소)
파일 이름에 허용되는 문자를 제외한 모든 것'/'그리고.NUL('\0')
특징들
기록된 날짜작성(Otime),[4] 변경(mtime), 속성 변경(ctime) 및 액세스(atime)
날짜 범위1970-01-01T00:00:00Z의[5] 64비트 서명된 int 오프셋
날짜 해결나노초
특성POSIX 및 확장 속성
파일 시스템 권한POSIX 및 ACL
투과적 압축○ (zlib, LZO[6] 및 (4.14 이후) ZSTD[7])
투과적 암호화계획되어[8] 있다
데이터 중복 배제네, 그렇습니다[9].
카피 온 라이트네.
다른.
지원되는 운영 체제Linux, ReactOS[10]
웹 사이트btrfs.wiki.kernel.org Edit this at Wikidata

Btrfs(「더 나은 FS」,[8] 「버터 [11][12]FS」, 「b-tree FS」,[12] 또는 「스펠링」으로 발음)는, COW(Copy-on-Write) 원칙에 근거하는 파일 시스템과 논리 볼륨 매니저(Linux의 LVM과 혼동하지 말 것)를 조합한 컴퓨터 스토리지 형식입니다.2007년 Oracle Corporation에서 Linux에서 사용하기 위해 처음 설계되었으며, 2013년 11월부터 파일 시스템의 온디스크 포맷은 Linux [13]커널에서 안정적이라고 선언되었습니다.Oracle에 따르면 Btrfs는 진정한 [14]약자가 아닙니다.

Btrfs는 Linux 파일 시스템에서 [8]풀링, 스냅샷, 체크섬 및 통합된 멀티 디바이스 스패닝의 부족에 대처하기 위한 것입니다.Btrfs의 주요 저자인 Chris Mason은 "[Linux]가 사용 가능한 스토리지에 맞게 확장할 수 있도록 하는 것이 목표"라고 말했습니다.확장이란 단순히 스토리지를 관리하는 데 그치지 않고 깨끗한 인터페이스를 통해 스토리지를 관리하고 관리할 수 있다는 것을 의미하며, 이를 통해 사용 중인 스토리지를 확인하고 신뢰성을 높일 수 있습니다."[15]

역사

Btrfs 파일 시스템의 사용 정보 스크린샷

Btrfs의 핵심 데이터 구조인 Copy-on-Write B-Tree는 IBM 연구원 Ohad Radeh가 USENIX [16]2007에서 발표한 프레젠테이션에서 처음 제안되었습니다.Reiser에서 일하는 엔지니어 Chris Mason은당시 SUSE의 FS는 그해 말 Oracle에 입사하여 이러한 [17]B-Tree를 기반으로 한 새로운 파일 시스템에 대한 작업을 시작했습니다.

2008년 ext3 및 ext4 파일 시스템의 주요 개발자인 Theodore Tso는 ext4는 기능이 향상되었지만 큰 진보는 아니며 오래된 기술을 사용하며 임시방편이라고 말했습니다.Tso는 Btrfs가 "확장성, 신뢰성 및 관리의 [18]용이성이 향상되었기 때문에" 더 나은 방향이라고 말했습니다.Btrfs는 또한 "reiser 3/4과 동일한 디자인 아이디어 다수"[19]를 가지고 있습니다.

Btrfs 1.0은 최종 온디스크 포맷으로 당초 2008년 후반에 [20]출시될 예정이었으나 [21]2009년에 최종적으로 Linux 커널 메인라인에 채택되었습니다.몇몇 Linux 디스트리뷰션에서는 설치 [22][23][24]시 루트 파일 시스템의 시험적인 선택으로 Btrfs를 제공하기 시작했습니다.

2011년 7월에 Btrfs 자동 디플러그 및 스크러빙 기능이 Linux 커널 메인라인 [25]버전 3.0으로 통합되었습니다.오라클의 메이슨 외에 후지쯔의 Miao Xie가 퍼포먼스 [26]향상에 공헌했습니다.2012년 6월 Chris Mason은 Oracle을 떠나 Fusion-io로 향했고, 1년 후 Joseph Bacik과 함께 Facebook에 입사했다.두 회사 모두 Mason은 Btrfs에 [27][17]대한 연구를 계속했습니다.

2012년에는 2개의 Linux 디스트리뷰션이 Btrfs를 실험용에서 실제 가동 또는 지원 상태로 이행했습니다.Oracle Linux가 [28]3월에 이어 SUSE Linux Enterprise가 [29]8월에 출시되었습니다.

2015년에 Btrfs는 SUSE Linux Enterprise Server [30]12의 기본 파일 시스템으로 채택되었습니다.

2017년 8월 Red Hat은 Red Hat Enterprise Linux(RHEL) 7.4 릴리즈 노트에서 RHEL 6 베타 이후 "테크놀로지 프리뷰"로 포함되었던 Btrfs를 완전히 지원되는 기능으로 이전할 계획이 없다고 발표했으며, RHEL 7 [31]시리즈에서는 계속 사용할 수 있을 것이라고 언급했습니다.Btrfs는 2019년 [32]5월에 RHEL 8에서 제거되었다.RHEL은 RHEL 6의 ext4에서 RHEL [33]7의 XFS로 이행했습니다.

2020년에 Btrfs는 데스크톱 [34]변종용 Fedora 33의 기본 파일 시스템으로 선택되었습니다.

특징들

기능 목록

실장 완료

Linux 커널 버전 5.0에서 Btrfs는 다음 기능을 [35][36]구현하고 있습니다.

  • Copy-on-Write의 특성상 일부 구성에서는 대부분 자가 복구 가능
  • 온라인 조각 모음 및 자동 디플래그 마운트[25] 옵션
  • 온라인 볼륨 증가 및 축소
  • 온라인 차단 장치 추가 및 제거
  • 온라인 밸런싱(로드 밸런싱을 위해 블록 디바이스 간에 객체 이동)
  • 오프라인 파일 시스템[37] 검사
  • 온라인 데이터 스크러빙을 통해 중복 복사가 있는 파일에 대해 오류를 찾아 자동으로 수정
  • RAID 0, RAID 1, RAID[38] 10
  • 서브볼륨(각 디스크 파티션 내에 개별적으로 마운트 가능한 파일 시스템 루트)
  • zlib, LZO[6] 및 (4.14 이후) ZSTD를 [7]통한 투과적 압축, 파일 또는[39][40] 볼륨별로 구성 가능
  • 서브볼륨의 아토믹 쓰기 가능(쓰기 시 복사 사용) 또는 읽기[41] 전용 스냅샷
  • 파일 클로닝(리링크, Copy-on-Write)은cp --reflink <source file> <destination file>[42]
  • 데이터 및 메타데이터 체크섬(CRC-32C)[43]5.5 [44]이후 새로운 해시 함수 xxHash, SHA256, BLAKE2B가 구현되었습니다.
  • ext3/4에서 Btrfs로의 임플레이스 변환(롤백 사용).이 기능은 btrfs-progs 버전 4.0을 중심으로 회귀하여 4.[45]6에서 처음부터 다시 작성되었습니다.
  • 파일 시스템 시드라고 하는 읽기 전용 스토리지의 유니언 마운트(기입 가능한 Btrf의 [46]카피 온 라이트 백업으로 사용되는 읽기 전용 스토리지)
  • 블록 폐기(일부 가상화 설정에서 공간 재확보 및 TRIM으로 SSD 마모 레벨링 향상)
  • 송수신(스냅샷 간의 차이를 바이너리 [47]스트림에 저장)
  • 증분 백업[48]
  • 대역외 데이터 중복 배제(사용자 공간 [9]도구 필요)
  • 스왑 파일 및 스왑 파티션 처리 기능

실장되어 있으나 실가동 용도로는 권장되지 않습니다.

계획 중이지만 아직 구현되지 않음

2009년에 Btrfs는 Sun Microsystems가 [57]개발한 ZFS에 필적하는 기능을 제공할 것으로 기대되었습니다.2009년 Oracle이 Sun을 인수한 후 Mason과 Oracle은 Btrfs [58]개발을 계속하기로 결정했습니다.

클로닝

Btrfs는 파일의 Copy-on-Write 스냅샷을 원자적으로 생성하는 복제 작업을 제공합니다.이와 같이 복제된 파일은 Linux 커널시스템 [59]콜에 따라 리플링크라고 불리기도 합니다.

클로닝을 통해 파일 시스템은 기존 inode를 가리키는 새 링크를 만드는 것이 아니라 원래 파일과 동일한 디스크 블록을 처음 공유하는 새 inode를 만듭니다.따라서 복제는 동일한 Btrfs 파일 시스템의 경계 내에서만 작동하지만 Linux 커널 버전 3.6 이후로는 특정 상황에서 [60][61]하위 볼륨의 경계를 넘을 수 있습니다.실제 데이터 블록은 복제되지 않습니다.또한 Btrfs의 Copy-on-Write(CoW; 쓰기 시 복사) 특성으로 인해 클론된 파일의 수정 내용은 원본 파일에 표시되지 않습니다.또,[62] 그 반대도 마찬가지입니다.

복제는 여러 파일 이름을 하나의 파일에 연관짓는 디렉토리 엔트리인 하드링크와 혼동하지 마십시오.하드 링크는 같은 파일의 다른 이름으로 간주할 수 있지만, Btrfs에서의 클로닝은 처음에 모든 디스크 [62][63]블록을 공유하는 독립된 파일을 제공합니다.

이 Btrfs 기능의 지원은 GNU coreutils 버전7.5에서 추가되어 있습니다.--reflink옵션cp명령어를 [64][65]입력합니다.

데이터 클로닝(FICLONE), Btrfs는 FIDEDUPERANGE를 통한 대역외 중복 배제도 지원합니다.이 기능을 사용하면,[66][9] 데이터가 같은 2개의 파일(일부라도)이 스토리지를 공유할 수 있습니다.

서브볼륨 및 스냅샷

스냅퍼로 관리되는 Btrfs 파일 시스템의 스냅샷 예제

Btrfs 서브볼륨은 개별 POSIX 파일 네임스페이스로 간주할 수 있습니다.이러한 서브볼륨은 POSIX 파일 네임스페이스에 따라 개별적으로 마운트할 수 있습니다.subvol또는subvolid옵션을 선택합니다.최상위 하위 볼륨을 마운트하여 액세스할 수도 있습니다. 이 경우 하위 볼륨이 표시되며 하위 [67]디렉토리로 액세스할 수 있습니다.

하위 볼륨은 파일 시스템 계층 내의 모든 위치에 생성할 수 있으며 중첩될 수도 있습니다.상위 하위 볼륨이 하위 디렉토리로 하위 볼륨을 표시하는 방식과 유사하게 중첩된 하위 볼륨은 상위 하위 볼륨 내에서 하위 디렉토리로 표시됩니다.하위 볼륨을 삭제하려면 중첩 계층에서 하위 볼륨 아래의 모든 하위 볼륨을 삭제해야 합니다. 따라서 최상위 하위 볼륨을 [68]삭제할 수 있습니다.

모든 Btrfs 파일 시스템에는 항상 기본 서브볼륨이 있습니다.이 서브볼륨은 처음에 최상위 서브볼륨으로 설정되어 서브볼륨 선택 옵션이 전달되지 않으면 기본적으로 마운트됩니다.mount기본 서브볼륨은 [68]필요에 따라 변경할 수 있습니다.

Btrfs 스냅샷은 Btrfs의 Copy-on-Write 기능을 사용하여 데이터(및 메타데이터)를 다른 서브볼륨과 공유하는 서브볼륨이며 스냅샷에 대한 수정 내용은 원래 서브볼륨에 표시되지 않습니다.쓰기 가능한 스냅샷이 만들어지면 원래 파일 시스템의 대체 버전으로 취급할 수 있습니다.예를 들어 스냅샷으로 롤백하려면 수정된 원래 하위 볼륨을 마운트 해제하고 대신 스냅샷을 마운트해야 합니다.이 시점에서 원래 서브볼륨도 [67]삭제할 수 있습니다.

Btrfs의 Copy-on-Write(CoW; 쓰기 시 복사) 특성은 초기에 Disk 공간을 거의 사용하지 않으면서 스냅샷이 빠르게 생성된다는 것을 의미합니다.스냅샷은 하위 볼륨이므로 중첩된 스냅샷을 생성할 수도 있습니다.서브볼륨의 스냅샷 작성은 재귀적인 프로세스가 아니기 때문에 서브볼륨의 스냅샷이 생성되면 서브볼륨에 이미 포함되어 있는 모든 서브볼륨 또는 스냅샷은 스냅샷 [67][68]내의 같은 이름의 빈 디렉토리에 매핑됩니다.

하위 볼륨에만 스냅샷이 있을 수 있으므로 디렉토리의 스냅샷을 생성할 수 없습니다.그러나 서브볼륨에 분산된 리링크와 관련된 회피책이 있습니다.새로운 서브볼륨이 생성되어 타깃디렉토리의 콘텐츠에 대한 크로스 서브볼륨 리링크가 포함됩니다.이 기능을 사용할 수 있으면 이 [60]새 볼륨의 스냅샷을 생성할 수 있습니다.

Btrfs의 서브볼륨은 기존의 LVM(논리볼륨 매니저) 논리볼륨과는 크게 다릅니다.LVM에서는 논리볼륨은 별도의 블록디바이스이지만 Btrfs 서브볼륨은 그렇지 않기 때문에 이러한 방법으로 [67]처리하거나 사용할 수 없습니다.btrfs의 dd 또는 LVM 스냅샷을 만들면 원본 또는 복사본 중 하나가 같은 [69]컴퓨터에 마운트된 경우 데이터 로스가 발생합니다.

송신-수신

임의의 서브볼륨(또는 스냅샷) 쌍이 지정되면 Btrfs는 (binary diff를 사용하여) 그 사이에 바이너리 diff를 생성할 수 있습니다.btrfs send명령) 나중에 재생할 수 있는 명령어btrfs receive다른 Btrfs 파일시스템에 있을 수 있습니다.송신-수신 기능은, 1 개의 서브 볼륨을 다른 [47][70]서브 볼륨으로 변환하기 위해서 필요한 데이터 수정 세트를 효과적으로 작성(적용)합니다.

송신/수신 기능은, 파일 시스템 레플리케이션의 심플한 형식을 실장하거나 증분 [47][70]백업을 실시하기 위해서, 정기적으로 스케줄 된 스냅샷과 함께 사용할 수 있습니다.

쿼터 그룹

Btrfs 쿼터 그룹의 예

쿼터 그룹(또는 qgroup)은 서브볼륨 또는 스냅샷이 소비할 수 있는 공간의 상한을 설정합니다.새 스냅샷은 데이터가 상위 스냅샷과 공유되기 때문에 처음에는 할당량을 소비하지 않지만 이후 새 파일 및 기존 파일의 쓰기 시 복사 작업에 대한 비용이 발생합니다.쿼터가 활성화되면 새로운 서브볼륨 또는 스냅샷별로 쿼터 그룹이 자동으로 생성됩니다.이러한 초기 쿼터 그룹은 그룹화할 수 있는 구성 블록입니다.btrfs qgroup명령어)를 계층에 배치하여 [49]쿼터 풀을 구현합니다.

할당량 그룹은 하위 볼륨 및 스냅샷에만 적용되며 개별 하위 디렉토리, 사용자 또는 사용자 그룹에 할당량을 적용할 수 없습니다.그러나 할당량을 적용해야 하는 모든 사용자 또는 사용자 그룹에 대해 서로 다른 하위 볼륨을 사용하면 해결 방법이 있습니다.

내선 2/3/4 및 라이저로부터의 임플레이스 변환FS

고정된 위치에 고정된 메타데이터가 거의 없기 때문에 Btrfs는 백엔드 스토리지 디바이스의 비정상적인 공간 레이아웃에 맞게 변형될 수 있습니다.그btrfs-convert툴은 이 기능을 이용하여 ext2/3/4 또는 라이저를 인플레이스 변환합니다.FS 파일 시스템은 원래 파일 [71]시스템의 수정되지 않은 복사본을 유지하면서 할당되지 않은 공간에 동등한 Btrfs 메타데이터를 중첩합니다.

변환에는 ext2/3/4 메타데이터 전체의 복사가 포함되어 있습니다.Btrfs 파일은 ext2/3/4 파일에 사용되는 블록과 같은 블록을 가리킵니다.따라서 변환이 영속화되기 전에 2개의 파일시스템 간에 공유되는 블록의 대부분이 됩니다.Btrfs의 Copy-on-Write 특성 덕분에 모든 파일 수정 시 파일 데이터 블록의 원래 버전이 유지됩니다.변환이 영속화될 때까지 ext2/3/4에서 free로 마크된 블록만이 새로운 Btrfs [71]변경을 유지하기 위해 사용됩니다.즉, 변환을 언제든지 취소할 수 있습니다(단, 그렇게 하면 Btrfs로의 변환 후에 이루어진 변경은 모두 지워집니다).

변환된 모든 파일은 Btrfs의 기본 하위 볼륨에서 사용 가능하고 쓸 수 있습니다.원래 ext2/3/4 파일 시스템에 대한 모든 참조를 저장하는 스파스 파일이 별도의 서브볼륨에 생성되며, 읽기 전용 디스크 이미지로 마운트되어 원본 파일 시스템과 변환된 파일 시스템 모두에 동시에 액세스할 수 있습니다.이 스파스 파일을 삭제하면 공간이 해방되어 변환이 [71]영속적으로 됩니다.

메인라인 Linux 커널의 4.x 버전에서는 in-place ext3/4 변환은 테스트되지 않은 것으로 간주되어 거의 [71]사용되지 않았습니다.단, 이 기능은 2016년에 새로 고쳐졌습니다.btrfs-progs4.6.[45] 이후 안정적이라고 간주되어 왔다.

라이저로부터의 임플레이스 변환FS는 2017년 9월에 커널 4.13과 [72]함께 도입되었습니다.

유니언 마운트/시드 장치

새로운 Btrfs를 작성할 때 기존 Btrfs를 읽기 전용 "시드" 파일 [73]시스템으로 사용할 수 있습니다.새로운 파일 시스템은 시드의 Copy-on-Write 오버레이로 기능하며 유니언 마운트의 한 형태로 기능합니다.시드는 나중에 Btrfs에서 분리할 수 있습니다.이 시점에서 리밸런서는 분리하기 전에 새로운 파일시스템이 참조하는 시드 데이터를 복사하기만 하면 됩니다.Mason은 Live CD instra에 도움이 될 수 있다고 제안했습니다.Live CD instra는 광디스크의 읽기 전용 Btrfs 시드에서 기동하여 사용자가 작업을 계속하는 동안 백그라운드에서 설치 디스크의 타깃 파티션으로 재밸런싱한 후 디스크를 [74]꺼내 재기동하지 않고 설치를 완료할 수 있습니다.

암호화

2009년 인터뷰에서 Chris Mason은 Btrfs에 [75]대한 암호화 지원이 계획되어 있다고 말했습니다.한편, 암호화를 Btrfs 와 조합하는 경우의 회피책은, 기반이 되는 디바이스상에서 dm-crypt / LUKS 등의 풀 디스크 암호화 메커니즘을 사용하고, 그 레이어 위에 Btrfs 파일 시스템을 작성하는 것입니다.

2020년 현재 개발자들은 HMAC(SHA256)[76]와 같은 키 해시를 추가하기 위해 노력하고 있습니다.

확인 및 복구

UNIX 시스템은 전통적으로 파일 시스템을 검사하고 복구하기 위해 "fsck" 프로그램을 사용합니다.이 기능은 를 통해 구현됩니다.btrfs check프로그램.버전 4.0 이후 이 기능은 비교적 안정적인 것으로 간주됩니다.그러나 2017년 8월 현재 btrfs 문서에서는 "개발자 또는 경험자"[77]로부터 조언을 받은 경우에만 수리 옵션을 사용하도록 되어 있습니다.

또 다른 툴이 있습니다.btrfs-restore(파손된 파일 시스템 자체를 변경하지 않고)[78] 마운트 불가능한 파일 시스템에서 파일을 복구하는 데 사용할 수 있습니다.

일반적으로 Btrfs는 대부분 자가 복구 기능을 하며 기본적으로 30초마다 데이터를 영구 스토리지에 정기적으로 플러시하기 때문에 마운트 시 손상된 루트 트리에서 복구할 수 있습니다.따라서 분리된 오류로 인해 다음 마운트 [79]시 최대 30초 동안 파일 시스템 변경이 손실됩니다.이 기간을 변경하려면 , 를 사용해 목적의 값(초단위)을 지정할 수 있습니다.commit마운트 옵션.[80][81]

설계.

USENIX 2007에서 Ohad Roadh의 최초 제안에 따르면 데이터베이스의 온디스크 데이터 구조로서 널리 사용되는 B+ 트리는 리프 노드가 서로 링크되어 있기 때문에 카피 온 라이트 기반의 스냅샷을 효율적으로 허가할 수 없습니다.리프가 카피 온 라이트인 경우, 형제자매와 부모도 카피 온 라이트 베이스의 스냅샷이 필요하게 됩니다.트리 전체가 복사될 때까지를 계속합니다.그는 대신 각 트리 노드에 관련된 refcount를 포함한 수정된 B-tree(리프 링크가 없음)를 제안했지만, 그것들을 쓰기 복사하기 쉽게 하기 위해 트리의 밸런싱 알고리즘에 대한 특정 완화 및 애드혹 프리 맵 구조에 저장했다.그 결과 우수한 [16]동시성을 유지하면서 쓰기 시 복사 스냅샷을 수행할 수 있는 고성능 개체 저장소에 적합한 데이터 구조가 구축됩니다.

같은 해 말 Oracle에서 Chris Mason은 이 데이터 구조를 메타데이터 및 파일 데이터뿐만 아니라 트리 자체의 공간 할당을 추적하기 위해 거의 독점적으로 사용하는 스냅샷 지원 파일 시스템에 대한 작업을 시작했습니다.이것에 의해, 모든 트래버설과 수정은 단일의 코드 패스를 개입시켜 실시할 수 있게 되었습니다.이것에 대해서, 카피 온 라이트, 체크 섬, 미러링등의 기능은, [57]파일 시스템 전체에 메리트를 주기 위해서 1회만 실장할 필요가 있었습니다.

Btrfs는 이러한 트리의 여러 계층으로 구성되며, 모두 동일한 B-트리 구현을 사용합니다.트리에는 136비트 키로 정렬된 일반 항목이 저장됩니다.키의 최상위 64비트는 하나의 객체 ID입니다.가운데 8비트는 항목 유형 필드입니다. 이 필드는 트리 검색에서 항목 필터로 코드에 유선 연결되어 있습니다.개체에는 여러 유형의 항목이 있을 수 있습니다.나머지(중요하지 않은) 64비트는 유형별로 사용됩니다.따라서 동일한 객체의 항목은 트리 내에서 서로 인접하여 유형별로 그룹화됩니다.오브젝트는 특정 키 값을 선택함으로써 같은 유형의 항목을 특정 [57][3]순서로 배치할 수 있습니다.

내부 트리 노드는 단순히 키와 포인터 쌍의 플랫리스트이며 포인터는 하위 노드의 논리 블록 번호입니다.리프 노드에는 노드 전면에 패킹된 항목 키와 끝에 패킹된 항목 데이터가 포함되며, 리프가 [57]채워질수록 두 데이터는 서로를 향해 커집니다.

파일 시스템 트리

각 디렉토리내에서 디렉토리 엔트리는 디렉토리 항목으로 표시됩니다.키 값의 최하위 비트는 파일명의 CRC32C 해시입니다.데이터는 위치 키 또는 이 키가 가리키는 inode 항목의 키입니다.따라서 디렉토리 항목은 함께 경로에서 inode로 검색하기 위한 인덱스로 기능할 수 있지만 해시별로 정렬되므로 반복에는 사용되지 않습니다.즉, 사용자 애플리케이션이 큰 디렉토리에서 반복하여 파일을 여는 경우 인접하지 않은 파일 간에 디스크 검색이 더 많아집니다. 즉, ReiserFS,[82] ext3(Htree-indexes가 활성화된[83] 경우), ext4와 같은 해시 순서가 지정된 다른 파일 시스템에서 성능 저하가 두드러집니다.이를 방지하기 위해 각 디렉토리 항목에는 디렉토리 인덱스 항목이 있으며, 이 항목의 키 값은 새로운 디렉토리 항목마다 증가하는 디렉토리별 카운터로 설정됩니다.따라서 이러한 인덱스 항목을 반복하면 디스크에 저장된 항목과 거의 동일한 순서로 항목이 반환됩니다.

여러 디렉토리에 하드링크가 있는 파일에는 부모 디렉토리마다 하나씩 여러 참조 항목이 있습니다.동일한 디렉토리에 여러 개의 하드 링크가 있는 파일은 링크의 모든 파일 이름을 동일한 참조 항목으로 패키지합니다.이는 동일한 디렉토리 하드 링크의 수를 단일 트리 블록에 들어갈 수 있는 개수로 제한하는 설계 결함입니다(기본 블록 크기 4KiB, 평균 파일 이름 길이 8바이트, 파일 이름당 헤더 4바이트에서는 350개 미만입니다).git, GNUS, GMame 및 Backup과 같은 여러 개의 동일한 디렉토리 하드 링크를 많이 사용한 응용 프로그램이 [84]제한으로 PC에 장애가 발생하였습니다.이 제한은 결국[85] 삭제되었습니다(및 2012년 10월 현재 Linux 3.7에서 보류 중인 릴리스에서 병합되었습니다[86]).확장 레퍼런스 아이템을 도입하여 다른 방법으로는 적합하지 않은 하드링크 파일명을 보유하게 되었습니다.

익스텐트

파일 데이터는 디스크 데이터 블록의 연속 실행인 익스텐트에서 트리 외부에 보관됩니다.익스텐트 블록의 크기는 기본적으로 4KiB이며 헤더는 없으며 파일 데이터(압축된 데이터일 수 있음)만 포함됩니다.압축 익스텐트에서는 개별 블록이 개별적으로 압축되지 않고 압축 스트림은 익스텐트 전체에 걸쳐 있습니다.

파일에는 내용을 보관하는 익스텐트를 추적하기 위한 익스텐트 데이터 항목이 있습니다.항목의 키 값은 익스텐트의 시작 바이트 오프셋입니다.따라서 특정 파일 오프셋에 대한 정확한 익스텐트는 하나의 트리 룩업으로 계산할 수 있기 때문에 익스텐트가 많은 대형 파일에서 효율적인 검색을 할 수 있습니다.

스냅샷과 복제된 파일은 익스텐트를 공유합니다.이러한 큰 익스텐트의 작은 부분을 덮어쓰면 덮어쓰기된 데이터가 포함된 작은 익스텐트와 덮어쓰기 양쪽에 수정되지 않은 데이터가 포함된 큰 익스텐트 두 개가 새로 생성됩니다.수정되지 않은 데이터를 다시 쓸 필요가 없도록 Copy-on-Write는 대신 북엔드 익스텐트 또는 단순히 기존 익스텐트의 슬라이스인 익스텐트를 작성할 수 있습니다.익스텐트 데이터 항목에서는 추적하는 범위에 오프셋을 포함하여 이를 허용합니다. 북엔드에 대한 항목은 [3]오프셋이 0이 아닌 항목입니다.

익스텐트 할당 트리

익스텐트 할당 트리는 파일 시스템의 할당 맵 역할을 합니다.다른 트리와 달리 이 트리의 항목에는 개체 ID가 없습니다.공간 영역을 나타냅니다. 키 값은 해당 영역이 나타내는 시작 오프셋과 길이를 유지합니다.

파일 시스템은 할당된 공간을 블록 그룹으로 나눕니다. 블록 그룹은 선호하는 메타데이터 익스텐트(트리 노드)와 데이터 익스텐트(파일 내용)를 번갈아 사용하는 가변 크기 할당 영역입니다.메타데이터 블록 그룹에 대한 데이터 기본 비율은 1:2입니다.이들은 Orlov 블록 할당자의 개념을 사용하여 관련 파일을 함께 할당하고 그룹 간에 여유 공간을 남겨두면 플래그멘테이션에 저항할 수 있습니다(단, Ext3 블록 그룹은 파일 시스템의 크기에서 계산된 고정 위치가 있는 반면 Btrfs의 블록 할당자는 동적이고 필요에 따라 생성됩니다).각 블록 그룹은 블록 그룹 항목과 연결됩니다.파일 시스템 트리의 inode 항목에는 현재 블록 [3]그룹에 대한 참조가 포함됩니다.

익스텐트 항목에는 해당 익스텐트를 점유하는 트리 노드 또는 파일에 대한 백 참조가 포함됩니다.스냅샷 간에 익스텐트가 공유되는 경우 여러 개의 백 참조가 있을 수 있습니다.항목에 맞지 않는 백 참조가 너무 많으면 개별 익스텐트 데이터 참조 항목으로 유출됩니다.또한 트리 노드에는 포함된 트리에 대한 백레퍼런스가 있습니다.이를 통해 영역 괄호로 묶은 오프셋 쌍에서 B-트리 범위 검색을 수행한 후 백레퍼런스를 따라가면 공간의 어느 영역 내에 있는 익스텐트 또는 트리 노드를 찾을 수 있습니다.이를 통해 데이터를 재배치할 때 전체 파일 시스템을 스캔하지 않고도 재배치된 블록에서 위쪽으로 효율적으로 이동할 수 있으므로 해당 블록에 대한 아래쪽 참조를 모두 신속하게 찾아 수정할 수 있습니다.따라서 파일 시스템은 스토리지를 온라인으로 효율적으로 축소, 마이그레이션 및 조각 모음을 수행할 수 있습니다.

익스텐트 할당 트리는 파일 시스템의 다른 모든 트리와 마찬가지로 Copy-on-Write입니다.따라서 파일 시스템에 쓰기를 수행하면 변경된 트리 노드와 파일 데이터가 새로운 익스텐트가 할당되어 익스텐트 트리 자체가 변경되는 캐스케이드가 발생할 수 있습니다.피드백 루프가 생성되지 않도록 하기 위해 아직 메모리에 있지만 디스크에 커밋되지 않은 익스텐트트리 노드를 갱신하여 새로운 쓰기 복사 익스텐트를 반영할 수 있습니다.

이론적으로 익스텐트 할당 트리는 익스텐트 할당 트리가 BSP 트리의 B 트리 버전으로 작용하기 때문에 기존의 자유 공간 비트맵을 불필요하게 만든다.단, 실제로는 페이지사이즈 비트맵의 인메모리 레드블랙 트리가 할당 속도를 높이기 위해 사용됩니다.이러한 비트맵은 디스크에 보관됩니다(Linux 2.6.37부터는space_cachemount[87] option)을 체크섬 및 Copy-on-write에서 면제되는 특수 익스텐트로 사용합니다.

체크섬 트리 및 스크러빙

다음 항목도 참조하십시오.사일런트 데이터 파손

CRC-32C 체크섬은 데이터와 메타데이터 모두에 대해 계산되어 체크섬트리에 체크섬 항목으로 저장됩니다.메타데이터 체크섬의 256비트와 데이터 체크섬의 최대 풀노드(약 4KB 이상)를 저장할 수 있는 공간이 있습니다.Btrfs에는 향후 버전의 파일시스템에 [35][88]추가될 체크섬알고리즘이 준비되어 있습니다.

할당된 블록의 연속 실행마다 체크섬 항목이 하나씩 있으며 블록별 체크섬이 항목 데이터에 엔드 투 엔드로 패킹됩니다.체크섬이 들어갈 수 있는 수보다 많을 경우 새 리프에서 다른 체크섬 항목으로 유출됩니다.파일 시스템은 블록 읽기 중에 체크섬 불일치를 검출하면 내부 미러링 또는 RAID 기술을 사용하는 [89][90]경우 먼저 다른 디바이스에서 이 블록의 양호한 복사본을 가져오거나 만듭니다.

Btrfs는 백그라운드에서 실행되는 파일 시스템 스크럽 작업을 트리거하여 파일 시스템 전체의 온라인 검사를 시작할 수 있습니다.스크럽 작업은 전체 파일 시스템의 무결성을 검사하고 [89][91]도중에 발견된 불량 블록을 자동으로 보고 및 복구하려고 시도합니다.

로그 트리

fsync 요구는 수정된 데이터를 즉시 안정된 스토리지에 커밋한다.fsync 부하가 높은 워크로드(OS fsync를 자주 실행하는 데이터베이스나 가상 머신 등)에서는 파일 시스템이 쓰기 시 복사 및 자주 수정되는 트리 부분의 플래시를 반복함으로써 대량의 중복 쓰기 I/O가 발생할 수 있습니다.이를 방지하기 위해 fsync 트리거 Copy-on-writes 저널링에 서브볼륨별 임시 로그트리가 생성됩니다.로그 트리는 자체 범위 추적과 자체 체크섬 항목 유지로 구성됩니다.해당 항목은 다음 전체 트리 커밋 시 또는 다음 재마운트 시(시스템 크래시가 발생한 경우) 재생 및 삭제됩니다.

청크 트리 및 디바이스 트리

블록 디바이스는 데이터의 경우 1 GiB, [92]메타데이터의 경우 256 MiB의 물리 청크로 나뉩니다.여러 디바이스에 걸친 물리적 청크를 미러링하거나 스트라이핑하여 하나의 논리 청크로 만들 수 있습니다.이러한 논리 청크는 파일 시스템의 나머지 부분에서 사용하는 단일 논리 주소 공간으로 결합됩니다.

청크 트리는 각 디바이스를 디바이스 항목으로 저장하고 논리 청크를 청크 맵 항목으로 저장하여 이를 추적합니다.이것에 의해, 키의 최하위 64 비트에 오프셋을 보존하는 것으로, 논리 주소로부터 물리 주소로 전송 매핑이 가능하게 됩니다.청크 맵 항목은 여러 가지 유형 중 하나입니다.

싱글
논리 1 대 물리 청크
이중
1개의 블록 디바이스에 1개의 논리 청크를 2개의 물리 청크로 연결
raid0
Nµ2 블록 디바이스 전체에서 Nµ2 물리 청크로 논리 청크 수
raid1
N개의 물리 청크가 있는 기존 RAID 1과는 달리 Nµ2 블록 디바이스 [93]중 2개의 물리 청크로 1개의 논리 청크를 2개의 물리 청크로 구성
raid1c3
Nµ3 블록 디바이스 중 논리 청크 1개에서 물리 청크 3개
raid1c4
Nµ4 블록 디바이스 중 논리 청크 1개에서 물리 청크 4개
RAID 5
N+1 블록 디바이스 전체에서 N+1 물리 청크로의 논리 청크(N22의 경우) 1 물리 청크를 패리티로 사용
raid6
N+2 블록 디바이스 전체에서 N+2 물리 청크로의 논리 청크를 N+2 로, 2 개의 물리 청크를 패리티로 사용합니다.

N은 청크가 할당되었을 때 사용 가능한 공간이 남아 있는 블록 디바이스 수입니다.N이 선택한 미러링/매핑에 충분한 크기가 아닐 경우 파일 시스템의 공간이 사실상 부족하게 됩니다.

재배치 트리

조각 모음, 축소 및 재조정 작업을 수행하려면 익스텐트를 재배치해야 합니다.그러나 재배치 익스텐트의 간단한 쓰기 복사를 수행하면 스냅샷 간의 공유가 중단되고 디스크 공간이 소모됩니다.공유를 유지하기 위해 업데이트 및 스왑 알고리즘이 사용되며, 영향을 받는 메타데이터의 스크래치 공간 역할을 하는 특별한 재배치 트리가 사용됩니다.재배치할 범위가 먼저 대상으로 복사됩니다.그런 다음 영향을 받는 서브볼륨의 파일시스템 트리에서 백레퍼런스를 위쪽으로 팔로우함으로써 오래된 익스텐트를 가리키는 메타데이터가 새로운 익스텐트를 가리키도록 순차적으로 갱신됩니다.새로 갱신된 항목은 재배치 트리에 저장됩니다.업데이트가 완료되면 재배치 트리의 항목이 영향을 받는 서브볼륨의 항목과 스왑되고 재배치 트리가 삭제됩니다.[94]

슈퍼블록

청크 트리 자체를 포함한 모든 파일 시스템의 트리는 청크에 저장되므로 파일 시스템을 마운트할 때 부트스트래핑 문제가 발생할 수 있습니다.마운트에 부트스트랩하려면 청크 트리와 루트 트리에 속하는 청크의 물리적 주소 목록이 슈퍼블록에 [95]저장됩니다.

슈퍼블록 미러는 고정 위치에 보관됩니다. 즉,[96] 64KiB가 모든 블록 장치에 적용되며, 추가 복사본은 64MiB, 256GiB 및 1PiB입니다.슈퍼블록 미러가 갱신되면, 그 생성 번호가 증가합니다.마운트 시에는 가장 높은 세대 번호를 가진 복사가 사용됩니다.일부 마모 레벨을 제공하기 위해 미러 간에 번갈아 업데이트를 제공하는 SSD 모드를 제외하고 모든 슈퍼 블록 미러가 동시에 업데이트됩니다.

상용 지원

서포트되고 있다

더 이상 지원되지 않음

「 」를 참조해 주세요.

메모들

  1. ^ a b 이것은 Btrfs 고유의 디스크 크기 제한입니다.Linux 커널의 내부 제한으로 인해 64비트 시스템에서는 8EiB로 제한되며 32비트 시스템에서는 2EiB로 제한됩니다.단, 커널의 내부 제한은 제외됩니다.CONFIG_LBD구성 옵션(2.6.x 커널 시리즈 이후 사용 가능)을 활성화하여 이러한 커널 [106][107]제한을 제거합니다.
  2. ^ Btrfs의 모든 항목은 64비트 식별자를 가집니다. 즉, Btrfs 파일 시스템에서 가질 수 있는 최대 파일은 2입니다64.

레퍼런스

  1. ^ "Btrfs Contributors at kernel.org". kernel.org. 18 January 2016. Retrieved 20 January 2016.
  2. ^ a b "Suse Documentation: Storage Administration Guide – Large File Support in Linux". SUSE. Retrieved 12 August 2015.
  3. ^ a b c d Mason, Chris. "Btrfs design". Btrfs wiki. Retrieved 8 November 2011.
  4. ^ Jonathan Corbet (26 July 2010). "File creation times". LWN.net. Retrieved 15 August 2015.
  5. ^ "On-disk Format - btrfs Wiki". btrfs.wiki.kernel.org.
  6. ^ a b "btrfs Wiki". kernel.org. Retrieved 19 April 2015.
  7. ^ a b "Linux_4.14 - Linux Kernel Newbies". kernelnewbies.org.
  8. ^ a b c d McPherson, Amanda (22 June 2009). "A Conversation with Chris Mason on BTRfs: the next generation file system for Linux". Linux Foundation. Archived from the original on 27 June 2012. Retrieved 1 September 2009.
  9. ^ a b c "Deduplication". kernel.org. Retrieved 19 April 2015.
  10. ^ "ReactOS 0.4.1 Released". reactos.org. Retrieved 11 August 2016.
  11. ^ "Archived copy". Event occurs at 1m 15s. Archived from the original on 18 August 2016. Retrieved 6 February 2016.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)
  12. ^ a b Henson, Valerie (31 January 2008). Chunkfs: Fast file system check and repair. Melbourne, Australia. Event occurs at 18m 49s. Retrieved 5 February 2008. It's called Butter FS or B-tree FS, but all the cool kids say Butter FS
  13. ^ "Linux kernel commit changing stability status in fs/btrfs/Kconfig". Retrieved 8 February 2019.
  14. ^ "22.2 About the Btrfs File System". Docs.Oracle.com. Oracle. 2018. Archived from the original on 28 April 2018. Retrieved 27 January 2021.
  15. ^ Kerner, Sean Michael (30 October 2008). "A Better File System for Linux?". InternetNews.com. Archived from the original on 8 April 2011. Retrieved 27 August 2020.
  16. ^ a b Rodeh, Ohad (2007). B-trees, shadowing, and clones (PDF). USENIX Linux Storage & Filesystem Workshop. 또
  17. ^ a b "Lead Btrfs File-System Developers Join Facebook". phoronix.com. Retrieved 19 April 2015.
  18. ^ Paul, Ryan (13 April 2009). "Panelists ponder the kernel at Linux Collaboration Summit". Ars Technica. Archived from the original on 17 June 2012. Retrieved 22 August 2009. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  19. ^ Ts'o, Theodore (1 August 2008). "Re: reiser4 for 2.6.27-rc1". linux-kernel (Mailing list). Retrieved 31 December 2010.
  20. ^ "Development timeline". Btrfs wiki. 11 December 2008. Archived from the original on 20 December 2008. Retrieved 5 November 2011.
  21. ^ Wuelfing, Britta (12 January 2009). "Kernel 2.6.29: Corbet Says Btrfs Next Generation Filesystem". Linux Magazine. Retrieved 5 November 2011.
  22. ^ a b "Red Hat Enterprise Linux 6 documentation: Technology Previews". Archived from the original on 28 May 2011. Retrieved 21 January 2011.
  23. ^ "Fedora Weekly News Issue 276". 25 May 2011.
  24. ^ "Debian 6.0 "Squeeze" released" (Press release). Debian. 6 February 2011. Retrieved 8 February 2011. Support has also been added for the ext4 and Btrfs filesystems...
  25. ^ a b "Linux kernel 3.0, Section 1.1. Btrfs: Automatic defragmentation, scrubbing, performance improvements". kernelnewbies.org. 21 July 2011. Retrieved 5 April 2016.
  26. ^ Leemhuis, Thorsten (21 June 2011). "Kernel Log: Coming in 3.0 (Part 2) - Filesystems". The H Open. Retrieved 8 November 2011.
  27. ^ Varghese, Sam. "iTWire". ITWire.com. Retrieved 19 April 2015.
  28. ^ "Unbreakable Enterprise Kernel Release 2 has been released". Retrieved 8 May 2019.
  29. ^ "SLES 11 SP2 Release Notes". 21 August 2012. Retrieved 29 August 2012.
  30. ^ "SUSE Linux Enterprise Server 12 Release Notes". 5 November 2015. Retrieved 20 January 2016.
  31. ^ a b "Red Hat Enterprise Linux 7.4 Release Notes, Chapter 53: Deprecated Functionality". 1 August 2017. Archived from the original on 8 August 2017. Retrieved 15 August 2017.
  32. ^ a b "Considerations in adopting RHEL 8". Product Documentation for Red Hat Enterprise Linux 8. Red Hat. Retrieved 9 May 2019.
  33. ^ "How to Choose Your Red Hat Enterprise Linux File System". Retrieved 3 January 2022.
  34. ^ "Btrfs Coming to Fedora 33". Fedora Magazine. 24 August 2020. Retrieved 25 August 2020.
  35. ^ a b c "Btrfs Wiki: Features". btrfs.wiki.kernel.org. 27 November 2013. Retrieved 27 November 2013.
  36. ^ "Btrfs Wiki: Changelog". btrfs.wiki.kernel.org. 29 May 2019. Retrieved 27 November 2013.
  37. ^ "Manpage btrfs-check".
  38. ^ "Using Btrfs with Multiple Devices". kernel.org. 7 November 2013. Retrieved 20 November 2013.
  39. ^ "Compression". kernel.org. 25 June 2013. Retrieved 1 April 2014.
  40. ^ "Btrfs: add support for inode properties". kernel.org. 28 January 2014. Retrieved 1 April 2014.
  41. ^ "btrfs: Readonly snapshots". Retrieved 12 December 2011.
  42. ^ "Save disk space on Linux by cloning files on Btrfs and OCFS2". Retrieved 1 August 2017.
  43. ^ "Wiki FAQ: What checksum function does Btrfs use?". Btrfs wiki. Retrieved 15 June 2009.
  44. ^ "Btrfs hilights in 5.5: new hashes". Retrieved 29 August 2020.
  45. ^ a b "Btrfs progs release 4.6". Retrieved 1 August 2017.
  46. ^ Mason, Chris (12 January 2009). "Btrfs changelog". Archived from the original on 29 February 2012. Retrieved 12 February 2012.
  47. ^ a b c Corbet, Jonathan (11 July 2012), Btrfs send/receive, LWN.net, retrieved 14 November 2012
  48. ^ "Btrfs Wiki: Incremental Backup". 27 May 2013. Retrieved 27 November 2013.
  49. ^ a b Jansen, Arne (2011), Btrfs Subvolume Quota Groups (PDF), Strato AG, retrieved 14 November 2012
  50. ^ btrfs (16 July 2016). "RAID 5/6". kernel.org. Retrieved 1 October 2016.
  51. ^ Zygo Blaxell. "How to use btrfs raid5 successfully(ish)". lore.kernel.org. Retrieved 26 June 2022.
  52. ^ Zygo Blaxell. "Current bugs with operational impact on btrfs raid5". lore.kernel.org. Retrieved 26 June 2022.
  53. ^ Corbet, Jonathan (2 November 2011). "A btrfs update at LinuxCon Europe". Retrieved 12 February 2012.
  54. ^ Mazzoleni, Andrea. "btrfs: lib: raid: New RAID library supporting up to six parities". Retrieved 16 March 2014.
  55. ^ "Btrfs Project ideas". 21 February 2013. Retrieved 21 February 2013.
  56. ^ Dorminy, Sweet Tea (13 July 2022). "btrfs: add fscrypt integration". Retrieved 1 August 2022.
  57. ^ a b c d Aurora, Valerie (22 July 2009). "A short history of btrfs". LWN.net. Retrieved 5 November 2011.
  58. ^ Hilzinger, Marcel (22 April 2009). "Future of Btrfs Secured". Linux Magazine. Retrieved 5 November 2011.
  59. ^ Corbet, Jonathan (5 May 2009). "The two sides of reflink()". LWN.net. Retrieved 17 October 2013.
  60. ^ a b "UseCases – btrfs documentation". kernel.org. Retrieved 4 November 2013.
  61. ^ "btrfs: allow cross-subvolume file clone". github.com. Retrieved 4 November 2013.
  62. ^ "Symlinks reference names, hardlinks reference meta-data and reflinks reference data". pixelbeat.org. 27 October 2010. Retrieved 17 October 2013.
  63. ^ Meyering, Jim (20 August 2009). "GNU coreutils NEWS: Noteworthy changes in release 7.5". savannah.gnu.org. Retrieved 30 August 2009.
  64. ^ Scrivano, Giuseppe (1 August 2009). "cp: accept the --reflink option". savannah.gnu.org. Retrieved 2 November 2009.
  65. ^ ioctl_fideduperange(2) – Linux 프로그래머 매뉴얼– 시스템 콜
  66. ^ a b c d "SysadminGuide – Btrfs documentation". kernel.org. Retrieved 31 October 2013.
  67. ^ a b c "5.6 Creating Subvolumes and Snapshots [needs update]". oracle.com. 2013. Retrieved 31 October 2013.
  68. ^ "Gotchas - btrfs Wiki". btrfs.wiki.kernel.org.
  69. ^ a b "5.7 Using the Send/Receive Feature". oracle.com. 2013. Retrieved 31 October 2013.
  70. ^ a b c d Mason, Chris (25 June 2015). "Conversion from Ext3 (Btrfs documentation)". kernel.org. Retrieved 22 April 2016.
  71. ^ "btrfs-convert(8) manual page". Retrieved 24 April 2018.
  72. ^ "Seed device".
  73. ^ Mason, Chris (5 April 2012), Btrfs Filesystem: Status and New Features, Linux Foundation, retrieved 16 November 2012[영구 데드링크]
  74. ^ McPherson, Amanda (22 June 2009). "A Conversation with Chris Mason on BTRfs: the next generation file system for Linux". Linux Foundation. Archived from the original on 27 June 2012. Retrieved 9 October 2014. In future releases we plan to add online fsck, deduplication, encryption and other features that have been on admin wish lists for a long time.
  75. ^ Sterba, David. "authenticated file systems using HMAC(SHA256)". Lore.Kernel.org. Retrieved 25 April 2020.
  76. ^ "Btrfsck - btrfs Wiki". btrfs.wiki.kernel.org.
  77. ^ "Restore - btrfs Wiki". btrfs.wiki.kernel.org.
  78. ^ "Problem FAQ - btrfs Wiki". kernel.org. 31 July 2013. Retrieved 16 January 2014.
  79. ^ "kernel/git/torvalds/linux.git: Documentation: filesystems: add new btrfs mount options (Linux kernel source tree)". kernel.org. 21 November 2013. Retrieved 6 February 2014.
  80. ^ "Mount options - btrfs Wiki". kernel.org. 12 November 2013. Retrieved 16 January 2014.
  81. ^ Reiser, Hans (7 December 2001). "Re: Ext2 directory index: ALS paper and benchmarks". ReiserFS developers mailing list. Retrieved 28 August 2009.
  82. ^ Mason, Chris. "Acp". Oracle personal web page. Retrieved 5 November 2011.
  83. ^ Fasheh, Mark (9 October 2012). "btrfs: extended inode refs". Archived from the original on 15 April 2013. Retrieved 7 November 2012.
  84. ^ Torvalds, Linus (10 October 2012). "Pull btrfs update from Chris Mason". git.kernel.org. Archived from the original on 15 April 2013. Retrieved 7 November 2012.
  85. ^ Larabel, Michael (24 December 2010). "Benchmarks of the Btrfs Space Cache Option". Phoronix. Retrieved 16 November 2012.
  86. ^ "FAQ - btrfs Wiki: What checksum function does Btrfs use?". The btrfs Project. Retrieved 22 November 2020.
  87. ^ a b Bierman, Margaret; Grimmer, Lenz (August 2012). "How I Use the Advanced Capabilities of Btrfs". Retrieved 20 September 2013.
  88. ^ Salter, Jim (15 January 2014). "Bitrot and Atomic COWs: Inside "Next-Gen" Filesystems". Ars Technica. Retrieved 15 January 2014.
  89. ^ Coekaerts, Wim (28 September 2011). "Btrfs Scrub – Go Fix Corruptions with Mirror Copies Please!". Retrieved 20 September 2013.
  90. ^ "Glossary". Btrfs Wiki. Retrieved 31 July 2021.
  91. ^ "Manpage/mkfs.btrfs". Btrfs Wiki. Profiles. Retrieved 31 July 2021.
  92. ^ Mason, Chris; Rodeh, Ohad; Bacik, Josef (9 July 2012), BTRFS: The Linux B-tree Filesystem (PDF), IBM Research, retrieved 12 November 2012
  93. ^ Mason, Chris (30 April 2008). "Multiple device support". Btrfs wiki. Archived from the original on 20 July 2011. Retrieved 5 November 2011.
  94. ^ Bartell, Sean (20 April 2010). "Re: Restoring BTRFS partition". linux-btrfs (Mailing list).
  95. ^ "Fedora 33 is Officially Here!". 27 October 2020. Retrieved 28 October 2020.
  96. ^ "Oracle Now Supports Btrfs RAID5/6 on Their Unbreakable Enterprise Kernel - Phoronix". Phoronix.com.
  97. ^ "Managing Btrfs in Oracle Linux 8". docs.oracle.com.
  98. ^ "SUSE Reaffirms Support for Btrfs". LWN.net.
  99. ^ "SUSE Linux Enterprise Server 12 Release Notes". SUSE.com. Retrieved 28 February 2021.
  100. ^ "Cloud Station White Paper" (PDF). Synology.com. Synology. p. 11. Retrieved 2 April 2021. Starting from DSM 6.0, data volumes can be formatted as Btrfs
  101. ^ "File Systems". ReactOS.org. Retrieved 28 February 2021.
  102. ^ "Btrfs has been deprecated in RHEL Hacker News". News.YCombinator.com.
  103. ^ "Red Hat Appears to Be Abandoning Their Btrfs Hopes - Phoronix". Phoronix.com.
  104. ^ Andreas Jaeger (15 February 2005). "Large File Support in Linux". users.suse.com. Retrieved 12 August 2015.
  105. ^ "Linux kernel configuration help for CONFIG_LBD in 2.6.29 on x86". kernel.xc.net. Archived from the original on 6 September 2015. Retrieved 12 August 2015.

외부 링크