본 글은 아래의 링크에 대한 한글 번역본입니다. [https://opensource.com/article/18/4/ext4-filesystem]
이전 배포판은 ext3, ext2 그리고 더 멀리 돌아가서 ext 를 기본으로 했었던 것처럼 현대 리눅스 배포판의 대부분은 ext4 파일시스템을 기본으로 합니다. (역자주: 현재는 suse 계열은 btrfs로 centos계열은 xfs가 기본으로 변경되었음.)
리눅스나 파일시스템이 처음 접한다면, ext3에 보다 추가된 ext4 기능에 대해 궁금할 것입니다. 또한, 현재 대안으로 나타나고 있는 btrfs, xfs, zfs에 비해 여전히 강점이 있는지도 궁금할 것입니다.
이 문서에서 파일시스템에 대한 모든것을 다룰 수는 없겠지만 우리는 리눅스의 파일시스템을 간단히 살펴보고, 현황과 전망에 대해서 이야기 할것입니다. 이글은 위키 피디아와 ext4에 관한 kernel.org 사이트와 경험을 바탕으로 작성되었습니다.
ext 파일시스템 전에, MINIX 파일 시스템이 있었습니다. MINIX는 IBM PC/AT 마이크로 컴퓨터를 위한 유닉스를 표방한 매우 작은 운영 체제였습니다. 1987년에 Andrew Tannenbaum은 교육 목적으로 MINIX를 개발하였고, 소스 코드를 발표했습니다.
MINIX의 소스코드를 보는것은 가능했지만, 그것은 실제 무료 오픈소스 소프트웨어(FOSS)는 아니였습니다. Tannebaum의 책은 비용과 라이센스 금액를 합해서 69 달러에 판매되었습니다. 그러나, 그 당시로서는 파격적으로 저렴한 가격이여서, 원래목적이였던 간단한 교육목적을 넘어서 급속히 확산되었습니다.
1990년대에 전 세계의 대학가에서 MINIX를 설치가 널리 퍼졌고, 이것은 Linux Torvalds는 1991년에 발표한 최초의 리눅스 커널 개발을 위해 MINIX 를 사용하였고, 이 리눅스커널을 1992년 12월에 GPL로 발표하게 됩니다.
파일시스템 이야기로 돌아가보자면, MINIX는 자체 파일시스템이 있었고, 초기 리눅스 역시 같은 파일시스템이었으나, 이는 장난감 수준의 파일시스템이었습니다. — MINIX 파일 시스템은 파일이름은 14 문자만 가능했으며, 단지 64MB의 저장공간만의 사용이 가능했습니다. 1991년에 이미 하드 드라이브의 크기가 40-140MB 크기였으니, 리눅스에는 더 향상된 파일 시스템이 필요했습니다.
Linux는 리눅스 커널에 초보적인 파일시스템을 사용하는 동안, Rémy Card는 첫번째 ext 파일 시스템에서 만들게 됩니다. 1992년에 처음 구현된 ext 는 – 리눅스가 발표된지 1년도 안된 시점- MINIX의 가장 최악의 문제를 해결했습니다.
1992년, ext는 Linux 커널에 새로운 추상화된 가상 파일 시스템 (VFS)을 사용했습니다. 이전의 MINIX 파일 시스템과 달리, ext은 최대 2GB의 저장 공간을 다룰 수 있고, 파일이름으로 255자를 사용할수 있었습니다.
하지만 ext는 원시적인 타임스탬프(파일당 오직 한개의 타임스탬프- 오늘날 익숙한 3개의 타임스탬프 -inode ,파일 접근,수정 용도)때문에 ext는 불과 1년 후, ext2로 대체되게 됩니다.
Rémy는 ext 파일 시스템의 한계를 인식하고 그것을 대체하기 위한 ext2 파일 시스템은 설계하게 됩니다. ext는 장난감 수준이였지만 ext2는 BSD’s Berkeley Fast File System과 동일한 원칙을 따라 상업용 파일시스템으로 설계되었습니다.
ext2는 파일크기가 gigabyte이상 파일시스템 크기는 terabyte 이상 사용가능하게 하며, 1990년대 파일시스템의 주류로 자리 잡았습니다. 빠르고 광범위하게 Linux커널과 MINIX 에도 채택되었으며, third-party 모듈을 통해 MacOS와 Windows에서 사용할 수 있도록 만들어졌습니다.
하지만 ext2파일 시스템은 여전히 해결해야 할 문제가 있었는데 이는 1990년대의 대부분의 파일 시스템과 마찬가지로 데이터를 디스크에 쓰는 동안 시스템이 크래쉬 상황이나 전원이 끊어지면 심각한 손상을 입는다는 것이었습니다. 시간이 지남에 따라 단편화(여러 위치에 단일 파일을 물리적으로 회전 디스크에 분산 저장)로 인해 성능이 크게 저하되기도 했습니다.
이러한 문제에도 불구하고 ext2는 오늘날에도 특수한 상황에서(가장 흔하게 휴대용 USB 드라이브 형태로) 여전히 사용되고 있습니다.
ext2를 채택된 지 6년 후인 1998년 Stephen Tweedie는 자신이 작업중인 상당히 개선된 버전의 파일시스템을 발표했습니다. 이것은 ext3로 2001년 11월에 리눅스 커널 버전 2.4.15에 채택되었습니다.
ext2는 대부분 Linux 배포 환경에서 매우 잘 실행되었지만 (FAT, FAT32, HFS및 다른 파일 시스템처럼) 정전 시 심각한 손상이 발생하기 쉬웠습니다. 파일 시스템에 데이터를 쓰는 동안 전원이 끊어지면 inconsistent state -(반은 쓰여졌고, 반은 쓰여지지 않은 상태)로 남게 됩니다. 이로 인해 저장되는 파일과 관련이 없는 큰 파일이 손실또는 손상되거나 심지어, 전체 파일시스템을 조작할수 없는 상태를 야기할수 있었습니다.
1990년대 후반, Ext3과 Microsoft NTFS와 같은 파일 시스템은 이 문제를 journaling을 사용하여 해결하게 됩니다. journal은 write 트랜잭션이 일어나는 디스크에 특정영역을 할당해 두고, 트랜잭션이 디스크에 쓰는 것을 완료하면 journal안의 데이터를 commit하게 되고, 해당 작업이 commit 되기전에 시스템이 손상을 입는다면 새로 재부팅된 시스템은 이를 불완전한 처리로 인식하고 저널영역만 없애고, 기존 파일시스템의 영역은 원래상태로 남겨두는 작업을 하게 됩니다.
즉, 작업 중인 파일이 여전히 손실될 수 있지만 파일 시스템 자체는 계속 일관되게 유지되고 다른 모든 데이터는 안전하게 보호됩니다. ext3의 리눅스 커널 구현에서 세가지 레벨의 journaling을 사용할 수 있습니다. 여기에는 Journal , Ordered 및 writeback 이 있습니다.
이전의 ext2와 마찬가지로 ext3은 16비트 내부 주소를 사용합니다. 즉, 블록 크기가 4K 인 경우 다룰 수 있는 가장 큰 파일크기는2TB이고, 최대 파일시스템 크기는 16TB입니다.
Theodore Ts’o(ext3의 핵심 개발자)는 2006년에 ext4 파일 시스템을 발표했고 2년 후 커널 버전 2.6.28d의 Linux에 추가되었습니다. Ts’o는 ext4가 ext3를 발전시킨 기술이지만 여전히 기존 기술에 의존한 중간단계이며, 결국 진정한 차세대 파일 시스템에 의해 대체될 것이라 이야기 합니다.
ext4는 기능적으로 ext3과 매우 유사하지만, 대용량 파일 시스템 지원을 제공하고 디스크 단편화에 대한 부분과 성능 증가, 타임 스탬프를 개선하였습니다.
ext4와 ext3 파일 시스템에서 몇 가지 차이점이 존재하며 이 번 섹션에서 설명합니다.
ext4는 가능한 ext3으로 호환되도록 특별히 설계되었습니다. 이는 ext3파일 시스템을 ext4로 업그레이드할 수 있도록 할 뿐 아니라 ext4 드라이버가 자동으로 ext3 파일 시스템을 ext3 모드로 마운트 할 수 있으므로 두 코드베이스를 별도로 유지 관리 할 필요가 없습니다.
Ext3파일 시스템이 32비트 주소 지정을 사용하여 최대 2TiB 파일, 16TiB파일 시스템의 제약 사항이 존재합니다.(4KiB 블록 크기의 경우 몇몇 Ext3파일 시스템은 더 작은 블록을 사용합니다)
ext4는 48비트 내부 주소 지정을 사용하여 최대 16TB의 파일을 파일시스템 1,000,000TiB( 1 EiB)까지 할당하는 것이 이론적으로 가능합니다. 일부 사용자 환경 유틸리티에 의해 초기 ext4는 16TiB파일 시스템으로 제한되었지만, 2011년부터 e2fsprogs를 통해 16TiB 이상의 ext4 파일 시스템 생성을 지원합니다. 한가지 예로, Red Hat Enterprise Linux는 공식적으로 ext4 파일 시스템을 최대 50TiB까지만 지원하며, 100TiB이하의 ext4 볼륨을 권장합니다.
Ext4는 스토리지 블록들의 읽기 및 쓰기 성능이 크게 향상될 수 있도록 디스크에 데이터를 쓰기 전에 할당하는 방식의 많은 개선사항을 도입하였습니다.
extent는 한번에 예약하여 처리할 수 있는 연속된 물리적 블록의 범위입니다. (4KiB 블록 크기라고 가정했을때 128MiB까지) extent 를 활용하면 지정된 파일에 필요한 inode들의 수을 줄이고 단편화를 감소시키며, 큰 용량의 파일을 쓸 때 성능을 향상시킬 수 있습니다.
Ext3는 새로운 블록이 할당될 때마다 블록할당자를 호출했습니다. 이는 다수의 writer가 동시에 작업을 하는 경우 심한 단편화를 쉽게 발생하게 합니다. 하지만 ext4는 아직 commit 하지 않은 쓰기에 대해 어떻게 할당것인지에 더 나은 의사결정과 여러 개의 쓰기를 하나로 합치도록 지연 할당을 사용합니다.
한 파일에 대해 파일에 대한 디스크 공간을 사전 할당할 때 대부분의 파일 시스템은 해당 블록에 0을 써야 합니다. ext4는 처음 쓰기 작업을 할 필요없이 공간 가용성을 확보(그리고 이를 위해 인접한 공간을 찾으려고 시도)하게 함으로써 fallocate()를 사용할 수 있도록 합니다. 이러한 작업은 스트리밍 및 데이터베이스 애플리케이션에 의해 기록된 데이터의 쓰기 및 향후 읽기 성능이 향상되도록 합니다.
지연 할당은 논쟁의 여지가 있는 기능입니다. 지연 할당은 ext4가 데이터를 디스크에 커밋할 준비가 될 때 데이터를 쓸 실제 블록을 할당하도록 합니다. (반면에 ext3은 데이터가 여전히 쓰기 캐시로 유입되는 동안에도 즉시 블록을 할당합니다)
캐쉬에 데이터가 누적될 때 블록 할당을 지연하는 것이 파일 시스템이 해당 블록을 할당하는 방법에 대해 보다 효율적으로 선택하여 단편화(쓰기 및 이후 읽기)를 줄이고 성능을 크게 향상합니다. 불행하게도, 프로그래머가 데이터가 디스크로 완전히 플러시 되는 것을 확인하려고 할 때, 특히 fsync()를 호출하도록 작성되지 않은 프로그램에서 데이터 손실 가능성을 높입니다.
프로그램이 파일을 완전히 다시 쓴다고 가정해 봅시다.
fd=open("file" ,O_TRUNC); write(fd, data); close(fd);
레거시 파일시스템의 close(fd) 는 디스크로 플러시될 file 의 내용을 보장하기에 충분합니다. 엄밀히 말하면, 비록 쓰기는 아니지만 파일을 닫은 후 충돌이 발생하면 데이터가 손실될 위험이 거의 없습니다.
쓰기가 성공하지 못한다면 (프로그램 오류, 디스크 오류, 전원 손실) 파일의 새 버전과 원래 버전이 모두 손실되거나 손상될 수 있습니다. 다른 프로세스가 파일이 기록되는 동안 파일에 접근 하는 경우 손상된 버전을 보게됩니다. 또한 다른 프로세스에서 파일을 열어 놓고 해당 내용이 변경될 것으로 예상하지 않으면 실행 중인 여러 프로그램으로 매핑 된 공유 라이브러리가 충돌할 수 있습니다.
이러한 문제를 피하기 위해 일부 프로그래머들은 O_TRUNC 를 전혀 사용하지 않습니다. 대신 새 파일에 쓰고 닫은 다음 이전 파일의 이름으로 바꿀겁니다.
fd=open("newfile"); write(fd, data); close(fd); rename("newfile", "file");
지연할당없는 파일 시스템은 위에서 설명한대로 잠재적 손상 및 충돌 문제를 방지하기에 충분합니다. rename() 은 atomic operation 이기 때문에 충돌에 의해 중단되지 않습니다 그리고 실행 중인 프로그램은 open filehandle 을 가지고 있는 한 이전의 지금은 링크되지않은 file 의 버전을 계속 참조합니다. 그러나 ext4의 지연 할당은 쓰기가 지연되고 순서를 변경할 수 있기때문에 rename(“newfile”, “file”) 은 newfile 의 내용이 실제로 디스크에 쓰여지기 전에 수행될 수 있어 file 의 잘못된 버전을 다시 가져오는 병렬 프로세스의 문제를 야기합니다.
이를 완화하기 위해 Linux커널(2.6.30 이후)은 이러한 일반적인 코드 사례를 탐지하고 문제의 파일을 즉시 할당하려고 시도합니다. 따라서 데이터 손실의 가능성이 줄어들지만 이를 방지할 수는 없으며, 새 파일에는 전혀 도움이 되지 않습니다. 여러분이 만약 개발자인 경우 참고하셔야 할 내용이 있는데 데이터가 디스크에 즉시 기록되도록 보장하는 유일한 방법은 fsync() 를 알맞게 호출하는 것입니다.
Ext3는 총 32,000개의 하위 디렉토리로 제한되어 있는 반면 ext4는 무제한의 숫자를 허용합니다. 커널 2.6.23으로 시작하는 ext4는 HTree 지수를 사용해 엄청난 수의 하위 디렉토리로 성능 손실을 완화합니다.
Ext3은 커널의 직접 제어 범위를 벗어나 자체 캐시가 있는 디스크 또는 컨트롤러 장치에 문제가 발생한 저널의 체크섬을 하지 않습니다. 자체 캐시가 있는 컨트롤러나 디스크가 순서를 위반한 경우, Ext3의 journaling 트랜잭션 순서가 해제되어 충돌 동안(또는 이전 기간 동안) 쓰여지고있던 파일이 손상될 수 있습니다.
이론적으로 이 문제는 파일 시스템이 마운트될 때 barrier=1 옵션을 사용하고 디바이스가 이후 fsync() 호출을 사용하여 쓰기에 대한 문제를 해결하였습니다. 실제로는 스토리지 디바이스와 컨트롤러의 쓰기 작업 성능 개선에 대해서는 어떨지 모르지만 데이터 손상을 막을 수 있는 방법에 대해서는 가능성을 열었습니다.
저널을 체크섬 하는 것은 파일 시스템이 깨진 후에 일부 항목이 잘못되었거나 최초 마운트 이후 비순차적이거나 유효하지 않은 일부 항목들을 알 수 있도록 합니다. 이로 인해 문제가 발생하는 특정 저널 항목이나 일부 엔트리의 롤백을 피하고 더 나아가 파일시스템을 손상시키는 것을 방지합니다.
ext3에서 fsck를 할때 전체 파일시스템(삭제되거나 빈 파일까지 포함해서)을 확인합니다. 그에 반해 ext4는 할당되지 않은 블록과 inode 테이블의 섹션을 표시하므로 fsck를 완전히 건너 뛸 수 있습니다. 이렇게하면 대부분의 파일 시스템에서 fsck를 실행할 시간이 크게 줄어들게 되는데 이 기능은 커널 2.6.24부터 적용되었습니다.
Ext3는 시간 스탬프를 1초 단위로 세분화하여 제공합니다. 대부분의 경우 사용할 수 있는 반면, mission-critical 애플리케이션의 경우 보다 엄격한 시간 제어가 요구됩니다. Ext4는 나노초단위로 시간 스탬프를 제공함으로써 엔터프라이즈, 과학기술 영역과 mission-critical 애플리케이션에서 사용이 가능합니다.
또한 Ext3 파일시스템은 2038년 1월 18일 이후로 날짜를 저장하기에 충분한 비트를 제공하지 않습니다. Ext4는 여기에 2비트를 더 추가하여 “유닉스 시대” 를 408년 더 연장합니다. 만일 2446년에 이것을 읽고 있다면, 아마 이미 더 나은 파일시스템으로 옮겨졌을 것입니다. — 하지만 1970년 1월 1일 UTC 00:00 이후로 시간을 계속 측정 중이라면 제가 죽은 후에라도 매우 기쁠 것 같습니다.
Ext2나 Ext3 모두 온라인 조각 모음을 직접 지원하지 않습니다. — 즉, 마운트된 동안 파일시스템을 조각모음하는 것. Ext2에는 이름에 함축 된대로 e2defrag 라는 유틸리티가 포함되어 있었습니다— 하지만, 파일 시스템을 마운트 하지 않은 상태에서 오프라인으로 실행해야 했습니다.(즉, 이것은 분명히 루트 파일 시스템에서 특히 문제가됩니다.) ext3은 심지어 ext2보다는 심각한 조각화로 인한 어려움을 훨씬 덜 겪었지만 ext3 파일 시스템에 대해 e2defrag를 실행하면 치명적인 손상과 데이터 손실을 초래할 수 있습니다.
ext3은 원래 “단편화에 영향을받지 않는것”으로 생각했지만 동일한 파일(예 : BitTorrent) 에 대용량 병렬 쓰기 를 하는 프로세스들은 그렇지 않은 것으로 입증되었습니다. Shake 와 같은 몇 가지 사용자 공간 해킹 및 해결 방법을 통해 이러한 문제를 해결했지만 실제 파일 시스템을 인식하는 커널 수준의 조각 모음 프로세스보다 속도가 느리고 다양한 방법으로 만족스럽지 않습니다.
Ext4는 온라인, 커널 모드, 파일 시스템 인식, 블록 및 확장 수준의 조각 모음 유틸리티 인 e4defrag를 사용해 이 문제를 해결합니다.
Ext4는 Monty Python 병 피해자가 말했던 것처럼 “ 아직 안죽었어요!” 비록 그것의 주요 개발자는 그것을 진정한 차세대 파일시스템으로 가는 임시방편에 불과하다고 생각하지만 어느 누구도 한동안 root 파일 시스템으로 배치될 준비가 되지 않을 것입니다(기술이나 라이센스 문제때문에).
메타 데이터의 체크섬, 1등급 할당량 지원 및 대형 할당 블록을 포함해, 아직도 몇가지 핵심적인 기능이 향후 버전의 ext4로 개발되고 있습니다.
ext4는 여분의 수퍼블록을 가지고 있기 때문에 그 안의 메타 데이터를 체크섬 해서 주요 슈퍼블록이 손상되고 대체가 사용할 필요가 있는지 스스로 파악하는 방법을 제공합니다. 체크섬없이 손상된 수퍼 블록에서 복구 할 수는 있지만 사용자는 먼저 손상되었는지 확인한 다음 대체 시스템을 사용하여 파일 시스템을 수동으로 마운트해야합니다. 손상된 주요 수퍼 블록가진 파일시스템을 read-write로 마운트할 때 경우에 따라 더많은 손상이 발생할 수 있습니다. 파일 시스템을 마운트 할 때 손상된 기본 슈퍼 블록을 사용하여 읽기 – 쓰기가 가능하기 때문에 경우에 따라 더 많은 손상이 발생할 수 있습니다. 충분한 경험이있는 사용자라 할지라도 충분한 해결책은 아닙니다!
btrfs 나 zfs같은 차세대 파일시스템이 제공하는 매우 강력한 블록단위 체크섬과 비교해서 ext4의 메타데이터 체크섬은 꽤 약한 기능입니다. 그러나 없는 것 보다는 훨씬 낫습니다.
쉬운결정 처럼 들리지만 – 그래, 모든것을 체크섬해 ! – 파일시스템에 체크섬을 결합하는 것은 몇가지 중요한 도전입니다; 자세한 내용은 설계 문서를 참조하세요.
잠깐만, 할당량?! 우리는 ext2 시대이후로 그것들을 가지고 있습니다! 네, 하지만 그것들은 항상 뒤늦어져왔고 좀 별로였습니다. 아마도 여기서 어려운 세부사항으로 들어가는 것은 별로 좋지않지만 설계 문서는 할당량이 사용자 공간에서 커널로 이동하고 더 정학하고 효율적으로 시행되는 방식을 설명합니다.
시간이 지남에 따라 이런 성가신 저장 시스템은 점점 더 커지고 있습니다. 이미 8K 하드웨어 블록사이즈를 사용하는 solid-state drive의 경우 ext4의 4K 블록에 대한 현재의 제한이 점점 더 제한됩니다. 더 커진 스토리지 블록은 단편화를 줄이고 증가된 여유 공간을 희생해서 (파일 또는 파일의 마지막조각을 저장하기 위해 블록의 일부만 필요로할 때 남은 공간) 성능을 크게 향상시킬 수 있습니다.
설계 문서에서 어려운 세부사항을 볼 수 있습니다.
Ext4는 견고하고 안정적인 파일시스템이며 2018년에는 대부분의 사람들이 루트 파일 시스템으로 사용해야 할 것입니다. 그러나 모든것을 다룰 수는 없습니다. 지금부터 ext4에서 기대하지 말아야 하는 것들에 대해 간단하게 말씀드리겠습니다
비록 ext4는 최대 1 EiB 의 데이터(1,000,000 TiB) 를 처리할 수 있지만 정말로 그렇게 시도하지는 말아야합니다. 단순히 더 많은 블록의 주소를 기억할 수 있는 것 이상의 규모 문제가 있으며 ext4는 현재 50-100 TiB 이상의 데이터를 처리할 수 없습니다. (아마 앞으로도 없을거같고)
또한 Ext4는 데이터 무결성을 보장하기에 충분하지 않습니다. journaling 같은 큰 발전이 ext3 시대에 뒷받침하고있어 데이터손상의 일반적인 원인을 많이 다루지는 않습니다. 이미 디스크에 있는 동안 데이터가 손상되었다면 -결점이 있는 하드웨어, 우주광선의 영향(네, 진짜로), 또는 시간 경과에 따른 단순한 저하 – ext4는 그런 손상을 발견하거나 고칠 방법이없습니다.
마지막 두개의 항목에 기초해서 ext4는 순수한 파일스템일 뿐이며 스토리지 볼륨 매니저가 아닙니다. 비록 다수의 디스크 – 그래서 이론적으로 손상된 데이터를 복구할 수 있는 패리티 또는 중복성- 가 있더라도 ext4는 그런 장점을 알거나 사용할 방법이 없다. 이론적으로 자동 손상 감지와 수리 기능을 잃지 않고 파일시스템과 스토리지 볼륨 관리시스템을 분리된 계층으로 나눌수 있지만 현재 스토리지 시스템은 그렇게 설계되어있지 않습니다. 그리고 새로운 디자인에 의미있는 도전이 될겁니다.
시작하기전에 주의사항: 배포판의 main 라인 커널의 일부로 내장되어 있지 않고 직접 지원하는 대체의 파일시스템을 매우 조심하세요!
비록 파일시스템이 안정하더라도 루트파일시스템으로 사용하는 것은 커널 업그레이드 중에 간단한 문제가 발생한다면 매우 무서울 수 있습니다. 대체 미디어로 부팅하고 수동으로 꾸준히 커널모듈, grub 설정, chroot로 부터 DKMS를 찔러보는 생각에 편안하지않다면 중요한 시스템의 루트파일시스템은 마음편히 하지마세요.
배포판에서 직접 지원하지 않는 파일시스템을 사용하는 것이 좋은 이유가 있을 수 있습니다 – 하지만 그렇게 한다면 시스템이 올라오고 사용할 수 있게 된후 마운트하길 강하게 추천드립니다. (예를 들어, ext4 루트 파일시스템을 가지고 있지만 데이터의 대부분은 zfs나 btrfs pool에 저장할 수 있습니다.
배포판에서 직접 지원하지 않는 파일 시스템을 사용하는 것이 좋은 이유가있을 수 있습니다. 그렇다면 시스템을 사용하고 사용할 수있게 된 후에 마운트하는 것이 좋습니다. (예를 들어, ext4 루트 파일 시스템을 가지고 있지만 대부분의 데이터를 zfs 또는 btrfs 풀에 저장할 수 있습니다.)
XFS는 Linux 에서 사용되는 non-ext 파일시스템의 거의 main 라인급입니다. 2001 년부터 리눅스 커널에 내장 된 64 비트 저널링 파일 시스템이며 대용량 파일시스템에 높은 성능과 높은 동시성을 제공합니다(즉, 정말 많은 수의 프로세스가 한번에 파일 시스템에 기록합니다.)
XFS는 RHEL7 부터 Red Hat Enterprise linux 의 기본 파일 시스템이 되었습니다. 가정이나 중소기업 사용자에게는 여전히 몇가지 단점이 있습니다. – 특히 기존 XFS파일시스템 크기를 조정하는게 매우 어려우며, 일반적으로 또다른 곳을 만들고 데이터를 복사하는 것이 더 합리적입니다.
XFS가 안정적이고 성능이 우수하지만 > 50TiB 용량 파일시스템같은 ext4가 가진 특정한 문제를 해결하지 않는 한, 기본 값(예:RHEL7)이 아닌 곳에서 사용을 권장하기에 ext4와의 구체적인 최종 사용 차이점이 없습니다.
XFS는 ZFS, btrfs 또는 WAFL(독점 SAN 파일시스템) 같은 방법으로 “차세대” 파일시스템은 아닙니다. ext4처럼 더 나은 것을 향한 길을 따라 임시 방편으로 간주될 가능성이 가장 높습니다.
ZFS는 Sun Microsystems에서 개발했으며 zettabyte -1조 기가와 동일 – 의 이름을 따서 명명되었으므로 이론적으로 큰 스토리지 시스템을 처리할 수 있습니다.
진정한 차세대 파일 시스템인 ZFS는 볼륨관리(단일 파일시스템에 여러개의 개별 저장 장치를 처리하는 기능), 블록 수준의 암호화 checksumming(매우 높은 정확도의 데이터 손상 탐지 가능), 자동 손상 복구(여분이나 패리티 스토리지가 사용가능한 곳), 신속한 비동기 증분 복제, 인라인 압축 등 훨씬 더 많이 제공합니다.
Linux 사용자의 관점에서 ZFS의 가장 큰 문제는 라이센스입니다. ZFS는 GPL과 충돌하는 반영구 라이센스인 CDDL을 허용합니다. 리눅스 커널에서 ZFS를 사용하는 것의 의미에 대해서는 “GPL위반이다”, “CDDL 위반이다”부터 “완벽히 괜찮다 단지 법정에서 판단되지 않았을뿐이다” 까지 다양한 의견으로 많은 논쟁이 있습니다. 특히 Canonical 은 지금까지 합법적 신청없이 2016년 이후로 커널에 ZFS code 라인을 포함시켰습니다.
현재로서는 열렬한 ZFS 사용자인데도 루트 파일시스템으로 ZFS를 추천하지 않습니다. 리눅스에 ZFS의 장점을 활용하려면 ext4에 소형 root 파일시스템을 설치한 후 나머지 저장공간에 ZFS를 설치하고 원하는 데이터, 애플리케이션을 배치합니다. – 다만, 배포판이 명시적으로 zfs를 root로 지원할때까지는 ext4를 root로 유지합니다.
B-Tree 파일시스템의 약자로 일반적으로 “butter”라고 발음하는 Btrfs 는 2007년에 Oracle 에서 재직중이던 Chris Mason 에 의해 발표되었습니다. Btrfs는 여러개의 장치 관리, 블록단위 checksumming, 비동기 복제, 인라인 압축 등등을 제공하는 ZFS와 거의 동일한 목표를 삼고 있습니다.
2018년부터 btrfs는 상당히 안정적이고 표준 단일 시스템으로 사용할 수 있지만 볼륨 관리자로 의존하지는 않아야 합니다. 많은 일반적인 사용 사례에서 ext4, XFS 또는 ZFS에 비해 상당한 성능 문제가 발생하며, 차세대 기능(복제, 다중 디스크 토폴로지와 스냅샷 관리)은 비극적으로 감소된 성능부터 실제 데이터 손실에 이르기까지의 크게 결함이 있을 수 있습니다.
진행중인 btrfs의 상태는 논란이 되고 있습니다. SUSE Enterprise Linux는 2015년에 기본 파일시스템으로 인정한 반면 Red Hat은 2017년 RHEL 7.4의 시작으로 btrfs를 지원하지 않는다고 발표했습니다. ZFS 같이 다중 디스크 볼륨 관리가 아닌 단일 디스크 파일시스템으로 btrfs의 운영과 지원되는 운영 환경 구축으로 사용하는 것에 주목할 가치가 있습니다. – 스토리지 어플라이언스에 btrfs를 사용하는 Synology도 기존의 Linux 커널 RAID (mdraid) 위에 계층화하여 디스크를 관리합니다.