| 항목 | 내용 |
|---|---|
| 프로젝트 | Linux Kernel |
| 관련 릴리스 | 7.1 (2026-06-14 tag) — 기능 자체는 7.1 머지 윈도우에서 ntfs-for-7.1-rc1-v2 태그로 2026-04-17에 mainline에 들어감 |
| 관련 커밋 | 병합 커밋 cdd4dc3a — Merge tag 'ntfs-for-7.1-rc1-v2' (ntfs resurrection, 46 commits), 배경이 된 이전 커밋 7ffa8f3d — fs: Remove NTFS classic (2024-01-15, Linux 6.9) |
| 작성자/리뷰어 | Namjae Jeon(구현, linkinjeon@kernel.org) — 공교롭게도 2024년 원본 드라이버 제거 커밋에 직접 Acked-by를 남긴 인물과 동일인, Christian Brauner(VFS 메인테이너, 병합) |
| 계기가 된 이슈 | Kari Argillander의 2022년 ntfs3 상태 보고서(병합 커밋 메시지가 인용, lore.kernel.org 원문은 접근 제한으로 직접 확인 불가 — 확인 필요), LWN이 취재한 ntfs3의 저조한 유지보수 이력(5.16에 패치 4건, 5.17에 1건 등) |
| 발견 출처 | LWN.net: "Filesystem medley: EROFS, NTFS, and XFS" (2026-01-23, Jonathan Corbet), kernelnewbies.org Linux_7.1 "NTFS Filesystem Implementation" 항목 |
| 검증 근거 | torvalds/linux 실제 커밋(fs/ntfs/Kconfig, fs/ntfs/super.c의 file_system_type 등록부, 46개 서브커밋 목록), 2024년 제거 커밋 원문, v7.1 이후에도 fs/ntfs에 이어지는 커밋 이력(7.2까지 계속 활발) |
Linux는 2021년 ntfs3(Paragon Software) 드라이버가 병합되며 처음으로 커널 자체 NTFS 쓰기 지원을 얻었고, 그 대가로 2024년 1월(Linux 6.9) 오래된 read-only fs/ntfs 드라이버는 "이제 쓸모없다"는 이유로 트리에서 완전히 제거됐다. 그런데 그로부터 약 2년 뒤인 Linux 7.1에서, 바로 그 제거 커밋에 승인(Acked-by)까지 했던 개발자 Namjae Jeon이 옛 read-only 드라이버의 코드베이스를 되살려 4년에 걸쳐 완전한 쓰기 지원·iomap 기반 I/O·folio 전환을 갖춘 새 드라이버로 다시 만들어 병합시켰다. ntfs3를 대체하는 것이 아니라 ntfs라는 별도 파일시스템 타입으로 나란히 공존하는 형태이며, 그 배경에는 "ntfs3가 병합 이후 유지보수가 지지부진했다"는 커뮤니티의 누적된 불만이 있다.
Windows의 기본 파일시스템인 NTFS를 리눅스 커널이 다루는 방법은 오래전부터 두 갈래로 나뉘어 있었다.
- 원조
fs/ntfs드라이버: 커널 초기부터 있던 것으로, 마운트해서 읽을 수는 있지만 쓰기는 지원하지 않았다(정확히는 매우 제한적인 in-place 쓰기만 가능했다). 실사용에서 NTFS에 쓰기가 필요한 사람들은 대신 사용자 공간 FUSE 구현인ntfs-3g를 썼다. ntfs3드라이버: Paragon Software가 개발해 2021년(Linux 5.15) 병합됐다. 커널 내장으로 진짜 읽기/쓰기를 지원한다는 점에서 원조 드라이버보다 명백히 발전된 것으로 받아들여졌다.
ntfs3가 "완전한 대체재"로 자리잡았다는 공감대 아래, VFS 메인테이너 진영(Christian Brauner, Matthew Wilcox 등)은 2024년 1월 원조 fs/ntfs를 트리에서 완전히 삭제했다(7ffa8f3d, Linux 6.9). 삭제 커밋 메시지는 "이미 여러 API의 마지막 사용자일 뿐이라 굳이 고쳐가며 남겨둘 가치가 없다"고 밝혔고, 당시 이 삭제에는 원조 드라이버의 원저자 계열인 Namjae Jeon도 직접 Acked-by를 남겼다.
전통적인 리눅스 파일시스템은 buffer_head 구조체로 페이지를 블록 단위 매핑과 엮어 버퍼드 I/O를 처리했다. iomap은 이를 대체하기 위해 도입된 더 단순한 계층으로, 파일시스템이 "이 범위는 이 디스크 위치에 매핑된다"는 익스텐트 정보만 iomap에 알려주면 나머지 페이지 캐시 상호작용(읽기/쓰기/direct I/O)은 공용 코드가 처리한다. folio는 여러 페이지를 하나의 단위로 묶어 다루는 최신 페이지 캐시 추상화로, buffer_head 기반 코드보다 대용량 I/O에서 오버헤드가 적다. 최근 병합되는 파일시스템 드라이버는 대부분 처음부터 iomap+folio 조합으로 작성되며, ntfs3는 이 전환 이전 세대의 buffer_head 인터페이스를 그대로 쓰고 있었다.
ntfs3 병합 이후 커뮤니티가 관찰한 것은 기대와 달리 유지보수 활동이 저조하다는 점이었다. LWN에 따르면 병합 직후인 5.16에는 패치가 4건, 5.17에는 단 1건만 반영됐고, 6.0 전후로 잠시 활동이 늘었다가 다시 줄어드는 패턴을 보였다. 최근 1년간 반영된 67개 커밋 중 상당수도 메인테이너 본인이 아니라 호환성 문제를 고치는 외부 기여자들이 올린 것이었다. Kari Argillander가 2022년 작성한 ntfs3 상태 보고서(병합 커밋이 직접 인용)가 이 문제를 공식적으로 짚었고, 이것이 Namjae Jeon이 대안을 준비하는 계기가 됐다(원문은 접근 제한으로 직접 확인하지 못해 확인 필요로 남긴다).
즉 "ntfs3가 원조 드라이버를 완전히 대체했다"는 2024년의 전제 자체가, 실제로는 유지보수 관점에서 흔들리고 있었던 셈이다. 하지만 이미 원조 드라이버는 트리에서 사라진 뒤였다.
[변경 전] 2021~2024: ntfs3가 유일한 커널 내장 read-write NTFS
┌─────────────┐ read-only ┌─────────────┐
│ fs/ntfs │───────────────▶│ 마운트된 │
│ (원조, RO) │ │ NTFS 볼륨 │
└─────────────┘ └──────▲──────┘
│ read/write
┌──────┴──────┐
│ ntfs3 │ buffer_head 기반
│ (Paragon) │ 유지보수 활동 저조
└─────────────┘
2024-01 (Linux 6.9): fs/ntfs 완전 삭제(7ffa8f3d)
→ "ntfs3가 완전한 대체재"라는 전제 하에 원조 드라이버 제거
→ 이후 ntfs3만 남았지만 유지보수 저조 문제는 해결되지 않음
Namjae Jeon은 삭제된 원조 read-only 드라이버의 "깨끗하고 주석이 풍부한" 코드베이스를 되살려 그 위에 4년간 작업을 쌓았다. 병합 커밋이 요약한 핵심 변경은 다음과 같다.
- 완전한 쓰기 지원: 클래식 read-only 드라이버 기반 위에 지연 할당(delayed allocation)을 추가해 멀티 클러스터 할당으로 쓰기 성능을 높이고 클러스터 비트맵 단편화를 줄였다.
- iomap 전환: 버퍼드 I/O(읽기/쓰기), direct I/O, 파일 익스텐트 매핑,
readpages/writepages를 모두 iomap 기반으로 바꿨다. buffer_head완전 제거: 전부 folio로 전환하면서CONFIG_BUFFER_HEAD의존성 자체를 Kconfig에서 없앴다.- 테스트 결과: xfstests 787개 중 326개 통과(ntfs3는 273개) — 병합 커밋은 ntfs3가 통과하는 테스트가 이 새 드라이버가 통과하는 테스트의 완전한 부분집합이라고 명시한다.
새 드라이버는 커널 내부 모듈명 ntfs, 파일시스템 타입 문자열도 "ntfs"로 등록되어(fs/ntfs/super.c의 ntfs_fs_type.name), mount -t ntfs3로 마운트하는 기존 ntfs3와 마운트 시점부터 이름이 겹치지 않는다 — 커널이 두 구현을 동시에 빌드해 나란히 공존시키는 이례적인 상태다. Linus Torvalds 본인의 병합 커밋 코멘트("이 되살아난 파일시스템이 '부활절의 기적' 쪽으로 갈지, '파일시스템계의 노스페라투' 쪽으로 갈지 지켜보자")가 이 상태의 잠정성을 잘 드러낸다. 커널 커뮤니티는 통상 동일 기능의 중복 구현을 반기지 않지만, 이번에는 예외적으로 두 드라이버의 공존을 허용한 상태에서 지켜보는 쪽을 택했다.
주의할 점은 이번 병합이 ntfs3를 대체·폐기하는 결정이 아니라는 것이다. ntfs3는 7.1 이후에도 자체 풀 리퀘스트를 통해 계속 별도로 유지보수되고 있다(예: 7.2용 ntfs3 병합 별도 진행). 저널링(journaling)도 새 드라이버에는 아직 없어 관련 xfstests 38개가 실패로 남아 있다.
두 가지 선택지가 있었을 것이다: ntfs3의 유지보수 문제를 그 코드베이스 안에서 직접 고치는 것, 아니면 이미 검증됐던 옛 코드베이스를 되살려 별도로 재작성하는 것. Namjae Jeon은 후자를 택했다 — 저장소 메시지에서 "ntfs3에는 여전히 문제가 많고 유지보수가 부실하다"고 직접적으로 표현한 것으로 알려져 있다(초기 ntfsplus 제안 당시).
- 대안 1 — ntfs3 내부 개선: 기존 코드베이스를 고수하며 점진적으로 개선. 원 유지보수자와의 협업이 필요하고, 이미 몇 년간 활동이 저조했던 프로젝트를 되살리는 데 걸리는 시간이 불확실하다는 리스크가 있다.
- 대안 2 — 옛 read-only 드라이버 재활용(채택): 이미 커널에 있었고 코드가 깔끔하다고 평가받던 원조 드라이버를 기반으로 새로 쓰기 지원과 최신 I/O 계층(iomap/folio)을 얹는다. 처음부터 새로 짜는 것보다 검증된 온디스크 포맷 파싱 로직을 재사용할 수 있지만, 결과적으로 커널에 동일 기능의 파일시스템 구현이 두 개 존재하게 된다.
커뮤니티가 이 중복을 받아들인 트레이드오프는 명확하다 — "정답이 검증되기 전까지는 두 구현을 공존시키고 실사용자와 xfstests 결과로 판단한다"는 것이다. 대신 감수해야 하는 비용은, 배포판·사용자 입장에서 당분간 "어떤 NTFS 드라이버를 써야 하는가"라는 선택지가 하나 더 늘었다는 점, 그리고 커널 메인테이너 입장에서 한동안 두 코드베이스를 함께 리뷰해야 한다는 점이다.
[변경 후] 7.1: 옛 드라이버가 재작성되어 ntfs3와 나란히 공존
┌───────────────────────┐ ┌───────────────────────┐
│ ntfs (신규, 재작성) │ │ ntfs3 (Paragon) │
│ - iomap 기반 I/O │ │ - buffer_head 기반 │
│ - folio, 쓰기 지원 │ │ - read/write │
│ - 저널링 없음 │ │ - 유지보수 활동 저조 │
│ - mount -t ntfs │ │ - mount -t ntfs3 │
│ - xfstests 326/787 │ │ - xfstests 273/787 │
└───────────┬───────────┘ └───────────┬───────────┘
│ │
└─────────────┬───────────────────┘
▼
사용자가 둘 중 하나를 골라 마운트
(같은 이름 충돌 없음, 커널이 둘 다 빌드)
- 저널링 미지원 상태(xfstests 실패 38건의 다수 원인)가 언제, 어떤 설계로 채워질까?
- 두 드라이버가 계속 별도로 유지보수되면 배포판들은 기본값을 어느 쪽으로 정할까 — 아니면 계속 공존시킬까?
- Kari Argillander의 2022년 ntfs3 보고서가 지적한 구체적 문제들이 새
ntfs드라이버에는 실제로 없는지, 시간이 지나며 재현되지는 않을지?
- 병합 커밋
cdd4dc3a— "Merge tag 'ntfs-for-7.1-rc1-v2': Pull ntfs resurrection from Namjae Jeon" 7ffa8f3d— "fs: Remove NTFS classic" (2024-01-15, Linux 6.9)- LWN.net: "Filesystem medley: EROFS, NTFS, and XFS"
- Linux_7.1 — Linux Kernel Newbies
- Kari Argillander의 2022년 ntfs3 상태 보고서 원문(lore.kernel.org) — 병합 커밋이 인용하지만 접근 제한(403)으로 원문을 직접 확인하지 못해 본문 인용은 병합 커밋의 인용문에 한정했다. 발견 시점 접근 실패로 1차 검증 불가.