Ext3
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
Ext3는 스티븐 트위디가 개발하고 2001년 리눅스 커널 2.4.15 버전에 통합된 저널링 파일 시스템이다. ext2 파일 시스템을 기반으로 하며, 저널링 기능을 통해 파일 시스템의 안정성과 복구 능력을 향상시켰다. ext2와의 높은 호환성을 제공하며, 온라인 파일 시스템 확장을 지원하지만, JFS, ReiserFS, XFS 등에 비해 속도가 느리고, 조각 모음 기능이 부족하다는 단점이 있다. ext3는 개별 파일 및 전체 파일 시스템 크기에 제한이 있으며, 삭제된 파일의 복구를 지원하지 않고, 스냅샷 기능과 저널 체크섬을 지원하지 않는다. ext3의 후속 버전은 ext4이다.
스티븐 트위디는 1998년 "리눅스 ext2fs 파일 시스템 저널링" 논문과 1999년 2월 커널 메일링 리스트 게시물을 통해 ext2 확장 작업을 공개했다. Ext3 파일 시스템은 2001년 11월 2.4.15 버전부터 메인라인 리눅스 커널에 통합되었다.[1]
ext2에서 자료 삭제 및 손실 없이 ext3으로 변경할 수 있다(자료를 백업할 필요가 없음). 저널링 기능으로 파일 시스템의 안정성과 복구 능력이 향상되었다.[9][10] 온라인 파일 시스템 증대 (확장) 기능으로 시스템 운영 중에도 파일 시스템 크기를 늘릴 수 있다. 큰 규모의 디렉터리를 위한 HTree (btree의 고급판) 인덱싱(dir_index 옵션)을 지원하여 디렉터리 검색 속도를 향상시켰다.[11]
JFS, ReiserFS, XFS 등에 비해 처리 속도가 느리다.[51] ext3는 ext2와의 호환성을 목표로 설계되어, inode의 동적 할당, 다양한 블록 크기(frag와 tail)와 같은 최신 파일 시스템 설계의 기능들이 부족하다.[16] 또한, 쓰기 모드로 마운트된 상태에서는 fsck를 할 수 없으며, 읽기-쓰기 모드로 마운트된 동안 수집된 파일 시스템의 덤프 작업은 데이터 손상을 야기할 수 있다.[3]
2. 역사
2. 1. 개발 배경
스티븐 트위디는 1998년 논문 "리눅스 ext2fs 파일 시스템 저널링"에서 ext2 확장에 대한 작업을 처음 공개했으며, 1999년 2월 커널 메일링 리스트 게시물을 통해 이를 다시 언급했다.[1] 이 파일 시스템은 2001년 11월 2.4.15 버전부터 메인라인 리눅스 커널에 통합되었다.[1]
3. 장점
ext2와의 높은 호환성 덕분에, e2fsprogs, fsck 등 ext2용으로 개발된 다양한 파일 시스템 관리 도구를 ext3에서도 그대로 사용할 수 있다. 벤치마크 결과에 따르면, ext3는 ReiserFS 및 XFS보다 CPU 자원을 덜 사용한다.[7][8]
4. 단점
ext3는 JFS, ext4, XFS와 같은 다른 파일 시스템에서 볼 수 있는 익스텐트 기능을 지원하지 않는다. 하위 디렉터리에 생성될 수 있는 서브디렉토리의 최대 수는 31998 개인데, 이는 아이노드가 32000개의 링크를 지원하기 때문이다. (./ 현재폴더, ../ 상위폴더 링크)[17]
ext3 파일 시스템을 위한 온라인 조각 모음 기능은 파일 시스템 레벨에서 제공되지 않는다. 오프라인 ext2 조각 모음기인 `e2defrag`가 있지만, ext3 파일 시스템은 먼저 ext2로 재변환해야 한다. `e2defrag`는 ext3의 새로운 기능을 처리하는 방법을 모르기 때문에 데이터를 손상시킬 수 있다.[51]
ext3는 기본적으로 투명 압축을 지원하지 않지만, 비공식 패치인 e3compr[31]을 통해 데이터 압축을 수행할 수 있다. 이 패치는 e2compr을 직접 포팅한 것이며, 추가적인 개발이 필요하다. 업스트림 커널에서 컴파일 및 부팅은 잘 되지만, 저널링은 아직 구현되지 않았다.
ext3는 개별 파일 및 전체 파일 시스템 크기에 제한을 둔다. 이러한 제한은 파일 시스템의 블록 크기에 따라 결정된다.[56]
8KiB 블록 크기는 8KiB 페이지를 허용하는 아키텍처에서만 가능하다.
Ext3는 저널에 기록할 때 체크섬 검사를 하지 않는다. ‘barrier=1’이 마운트 옵션(/etc/fstab)으로 활성화되지 않고, 하드웨어가 캐시에 기록되지 않을 때, 충돌이 일어나는 동안 심각한 파일 시스템 손상의 위험이 있다.[57]
4. 1. 기능 제한
ext3는 ext2와의 호환성을 우선시하여 설계되었기 때문에, 다음과 같은 최신 파일 시스템 기능이 부족하다.4. 2. 조각 모음
파일 시스템 레벨에서 사용할 수 있는 온라인 ext3 조각 모음 기능은 없다. 오프라인 ext2 조각 모음 도구인 `e2defrag`가 있지만, ext3 파일 시스템은 ext2로 먼저 재변환되어야 한다. `e2defrag`는 ext3의 새로운 기능들을 처리하는 방법을 알지 못하기 때문에 데이터를 손상시킬 수 있다.[51]
Shake[52]와 defrag[53] 같은 사용자 공간 조각 모음 도구들이 있다. Shake는 전체 파일을 위한 공간을 바로 할당하여 단편화가 적게 새 파일을 할당한다. 또한, 다음에 같이 사용되는 파일을 서로 근접하게 쓴다. Defrag는 각 파일을 스스로 복사하는 방식으로 작동한다. 그러나 이러한 도구들은 파일 시스템이 비어 있을 때만 작동하며, 실제로 ext3를 위한 조각 모음 도구는 아니다.[54]
'Linux System Administrator Guide'에서는 "현재의 리눅스 파일 시스템은 연속적인 섹터에 저장할 수 없는 경우에도 파일 상에서 모든 블록을 서로 근접하게 유지하여 단편화를 최소화한다. 따라서 리눅스 시스템에서 단편화를 걱정할 필요는 없다."라고 언급한다.[55]
하지만, 파일 단편화는 멀티미디어 서버 응용 프로그램과 같은 특정 환경에서 중요한 문제가 될 수 있다. ext3는 FAT 파일 시스템보다는 파일 단편화에 강하지만, 시간이 지남에 따라 단편화가 진행될 수 있다. ext3의 다음 버전인 ext4는 파일 시스템 조각 모음 유틸리티를 포함하며 익스텐트를 지원한다.
4. 3. 압축
ext3는 기본적으로 투명 압축을 지원하지 않는다. e3compr[31]은 ext3에 대한 비공식 패치로, 데이터 압축을 수행한다. e2compr을 직접 포팅한 것이며, 아직 추가 개발이 필요하다. 업스트림 커널에서 잘 컴파일되고 부팅되지만, 저널링은 아직 구현되지 않았다.
4. 4. 크기 제한
ext3는 개별 파일 및 전체 파일 시스템의 최대 크기에 제한을 두고 있다. 이러한 제한은 파일 시스템의 블록 크기에 따라 결정된다.[56]
8KiB 블록 크기는 8KiB 페이지를 허용하는 아키텍처에서만 사용할 수 있다.
4. 5. 삭제된 파일 복구 불가
ext3 드라이버는 충돌 안전성을 위해 파일 inode[27]를 지워 파일 삭제를 적극적으로 수행한다.파일 시스템 저널 분석을 사용하여 삭제되거나 손실된 파일을 복구하는 몇 가지 기술[28]과 일부 무료[29] 및 상용[30] 소프트웨어가 있지만, 특정 파일의 복구를 보장하지는 않는다.
4. 6. 스냅샷 미지원
스냅샷은 특정 시점의 파일 시스템 상태를 보존하는 기능인데, ext3는 이 기능을 기본적으로 지원하지 않는다. 대신, 리눅스 LVM에서 제공하는 볼륨 레벨 스냅샷 기능을 사용해야 하는데, 이는 공간 효율성이 떨어진다는 단점이 있다. Next3 파일 시스템은 ext3를 수정한 버전으로 스냅샷 기능을 지원하며, ext3와의 호환성도 유지한다.[32]4. 7. 저널 체크섬 미지원
Ext3는 저널에 기록할 때 체크섬 검사를 하지 않는다. ‘barrier=1’이 마운트 옵션(/etc/fstab)으로 활성화되지 않고, 하드웨어가 캐시에 기록되지 않을 때, 충돌이 일어나는 동안 심각한 파일 시스템 손상의 위험이 있다.[57] (이 옵션은 대부분의 리눅스 배포판에서 기본적으로 비활성화되어 있어, 대부분의 리눅스 배포판이 이러한 위험에 노출되어 있다는 것을 의미한다.)하드 디스크 쓰기가 제대로 작동하지 않는 경우 (쓰기 속도를 향상시키기 위한 하드 디스크 캐싱 때문에), 하드 디스크는 다른 관련된 블록에 쓰기가 실행되기 전에 하나의 트랜잭션의 commit 블록을 종종 쓰게 된다. 다른 블록에 쓰기가 되기 전에 전원 문제나 커널 패닉이 발생하면, 시스템은 재부팅을 해야만 하는 상태가 된다. 재부팅 시, 파일 시스템은 정상적으로 로그를 읽어 들여와서, 유효한 commit 블록이 있는 트랜잭션(유효하지 않은 트랜잭션을 포함)을 재실행한다. 종료되지 않은 디스크 쓰기는 결과적으로 진행되지만 손상된 저널 데이터를 사용하게 된다. 파일 시스템은 저널을 재실행하는 동안 손상된 데이터로 정상 데이터를 덮어쓰게 된다. 만일 체크섬이 사용되었더라면, 파일 시스템은 손상된 데이터를 다시 실행하지 않았을 것이다.
5. 저널링
ext2는 자료 삭제 및 손실 없이 ext3으로 변경할 수 있는데, 이는 저널링 기능이 추가되었기 때문이다. ext3는 시스템 충돌 후에도 파일 시스템의 내부 구조를 일관성 있게 유지하며, 수정 중이던 파일이나 디렉터리의 데이터 내용만 영향을 받고 나머지는 복구 후에도 그대로 유지된다.
Ext3를 지원하는 리눅스 시스템에서는 다음과 같은 세 가지 수준의 저널링을 사용할 수 있다.
- '''Journal (리스크 최소)'''
- '''Ordered (리스크 중간)'''
- '''Writeback (리스크 최고)'''
5. 1. Journal (최저 위험)
메타데이터와 파일 내용 모두 메인 파일 시스템에 커밋되기 전에 저널에 기록된다. 저널은 디스크에서 비교적 연속적이므로 저널에 충분한 공간이 있다면 성능을 향상시킬 수 있다. 그렇지 않은 경우 데이터가 두 번 쓰여져야 하므로 성능이 저하된다. 한 번은 저널에, 다른 한 번은 파일 시스템의 메인 부분에 쓰여진다.[14]5. 2. Ordered (중간 위험)
메타데이터만 저널링되고 파일 내용은 저널링되지 않지만, 파일 내용이 관련 메타데이터가 저널에 커밋됨으로 표시되기 전에 디스크에 기록되도록 보장된다. 이것은 많은 리눅스 배포판의 기본값이다. 파일 쓰기 또는 추가 중에 정전이나 커널 패닉이 발생하면 저널은 새 파일 또는 추가된 데이터가 커밋되지 않았음을 나타내므로 정리 프로세스에 의해 제거된다. 따라서 추가 및 새 파일은 저널링 수준과 동일한 수준의 무결성 보호를 받는다. 그러나 파일 덮어쓰기는 원본 파일 버전이 저장되지 않기 때문에 손상될 수 있다. 새 데이터도 이전 데이터도 복원할 정보가 충분하지 않은 상태로 파일이 중간 상태로 끝날 수 있다. 새 데이터는 디스크에 완전히 기록되지 않았고 이전 데이터는 어디에도 저장되지 않았기 때문이다. 더 나쁜 것은 쓰기 순서가 디스크 하드웨어에 맡겨지기 때문에 중간 상태가 이전 데이터와 새 데이터를 섞을 수 있다는 것이다.[49][50][14][15]5. 3. Writeback (최고 위험)
메타데이터만 저널에 기록되며, 파일의 내용은 기록되지 않는다. 파일 내용은 저널이 업데이트되기 전이나 후에 기록될 수 있으며, 결과적으로 충돌 직전에 수정된 파일들은 손상될 수 있다. 예를 들어, 추가되는 파일이 실제 크기보다 더 큰 파일로 저널에 기록되면, 결국은 "쓰레기(의미 없는 정보)"를 만들게 된다. 오래된 파일일수록 저널이 복구된 후에 예상치 못한 결과가 나타날 수 있다. 데이터와 저널 간의 동시성이 결여되며 대부분의 경우에서 점점 심해진다. JFS와 XFS는 이러한 저널링 레벨을 사용하지만, JFS의 경우 데이터를 기록하지 않기 때문에 모든 "쓰레기"는 재부팅 시 완전히 삭제된다.[49][50]세 가지 모드 모두에서, 시스템 충돌 후에도 파일 시스템의 내부 구조는 일관성을 유지한다.
6. 명세
| 항목 | 내용 |
|---|---|
| 개발자 | 스테판 트위디 (Stephen Tweedie) |
| 이름 | 3차 확장 파일 시스템 (Third Extended File System) |
| 배포 | 2001년 11월 (리눅스 2.4.15) |
| 파티션 식별자 | 0x83 (MBR), EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (GPT) |
| 구조 | |
| 디렉터리 내용 | 테이블, h-트리, dir_index |
| 파일 할당 | 비트맵 (여유 공간), 테이블 (메타데이터) |
| 배드 블록 | 테이블 |
| 제한 | |
| 최대 파일 크기 | 16GiB – 2TiB |
| 최대 파일 개수 | 파일 시스템 생성 시 다양하게 지정 가능[58] |
| 최대 파일 이름 길이 | 255 바이트 |
| 최대 볼륨 크기 | 2TiB – 32TiB |
| 파일 이름 허용 문자 | NUL 및 ‘/’를 제외한 모든 바이트 단위 문자 |
| 특징 | |
| 기록 날짜 | 수정 (mtime), 속성 수정 (ctime), 접근 (atime) |
| 날짜 표현 범위 | 1901년 12월 14일 - 2038년 1월 18일 |
| 날짜 표현 단위 | 1초 |
| 포크 (Forks) | |
| 속성 | No-atime, append-only, synchronous-write, no-dump, h-tree (directory), immutable, journal, secure-delete, top (directory), allow-undelete |
| 파일 시스템 권한 | 유닉스 권한, ACLs 및 임의의 보안 속성 (리눅스 2.6 이후 버전) |
| 투명 압축 | 지원 안함 |
| 투명 암호화 | 지원 안함 (블록 장치 레벨에서 제공됨) |
| 지원 OS | 리눅스, BSD, 윈도우 (IFS를 통해 지원) |
7. ext4
테오도어 초[45]는 2006년 6월 28일, ext3의 향상된 버전인 ext4를 발표했다. 2008년 10월 11일, ext4를 안정적인 코드로 표시하는 패치가 리눅스 2.6.28 소스 코드 저장소에 병합되어 개발 단계가 종료되었고, 채택을 권장했다.
2008년, 초는 ext4가 ext3보다 훨씬 빠르다는 개선된 기능을 가지고 있지만, 주요 발전은 아니며, 구형 기술을 사용하고, 임시 방편이라고 말했다. 초는 "확장성, 안정성 및 관리 용이성에서 개선을 제공한다"는 점에서 Btrfs가 더 나은 방향이라고 믿고 있다.[46] Btrfs는 또한 "reiser3/4와 동일한 설계 아이디어를 가지고 있다"고 한다.[47]
참조
[1]
문서
[2]
웹사이트
ReactOS 0.4.2 Released
https://reactos.org/[...]
2016-08-17
[3]
웹사이트
Chapter 6. The Ext4 File System Red Hat Enterprise Linux 6
https://access.redha[...]
[4]
간행물
Journaling the Linux ext2fs Filesystem
http://e2fsprogs.sou[...]
1998-05
[5]
웹사이트
Re: fsync on large files
http://marc.info/?l=[...]
1999-02-17
[6]
웹사이트
2.4.15-final
http://marc.info/?l=[...]
2001-11-23
[7]
간행물
Benchmarking Filesystems Part II
http://linuxgazette.[...]
[8]
간행물
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch
http://www.debian-ad[...]
2010-11-03
[9]
웹사이트
Introduction to Linux filesystems and files
http://www.linux.com[...]
Linux.com
2003-10-09
[10]
웹사이트
Which Linux filesystem to choose for your PC? Ext2, Ext3, Ext4, ReiserFS (Reiser3), Reiser4, XFS, Btrfs
http://linuxtweaks.w[...]
2010-04-23
[11]
웹사이트
Directory indexing
http://ext2.sourcefo[...]
2009-04-01
[12]
웹사이트
Documentation/filesystems/ext2.txt
http://lxr.linux.no/[...]
[13]
문서
[14]
웹사이트
Common threads: Advanced filesystem implementor's guide, Part 8
http://www.ibm.com/d[...]
2001-12-01
[15]
웹사이트
curious onloooker: Speeding up ext3 filesystems
http://evuraan.blogs[...]
2007-01-09
[16]
웹사이트
Extents, Delayed Allocation
http://ext2.sourcefo[...]
2008-07-30
[17]
웹사이트
Re: How many sub-directories ?
http://linux.derkeil[...]
2007-04-03
[18]
웹사이트
Post to the ext3-users mailing list
http://marc.info/?l=[...]
[19]
웹사이트
Shake
http://vleu.net/shak[...]
[20]
웹사이트
Defrag written in shell
http://ck.kolivas.or[...]
2012-08-19
[21]
웹사이트
Defrag written in Python
http://bazaar.launch[...]
[22]
웹사이트
RE: searching for ext3 defrag/file move program
http://www.redhat.co[...]
2005-03-04
[23]
웹사이트
5.10. Filesystems
http://www.tldp.org/[...]
2002-11-09
[24]
웹사이트
"#849 closed Enhancement (fixed) - preallocation to prevent fragmentation"
http://trac.transmis[...]
[25]
웹사이트
Tuning the Linux file system Ext3
http://www.heise-onl[...]
2008-10-27
[26]
웹사이트
Ext4 – Linux Kernel Newbies
http://kernelnewbies[...]
2011-05-19
[27]
웹사이트
Linux ext3 FAQ
http://batleth.sapie[...]
[28]
웹사이트
HOWTO recover deleted files on an ext3 file system
http://www.xs4all.nl[...]
2008-02-07
[29]
웹사이트
PhotoRec – GPL'd File Recovery
http://www.cgsecurit[...]
[30]
웹사이트
UFS Explorer Standard Recovery version 4
http://www.ufsexplor[...]
[31]
웹사이트
e3compr – ext3 compression
SourceForge:projects[...]
[32]
웹사이트
The Next3 filesystem
https://lwn.net/Arti[...]
LWN
[33]
웹사이트
Re: Frequent metadata corruption with ext3 + hard power-off
http://archives.free[...]
[34]
웹사이트
Re: Frequent metadata corruption with ext3 + hard power-off
http://archives.free[...]
[35]
문서
[36]
뉴스
ext4: Add the journal checksum feature
http://article.gmane[...]
Article.gmane.org
2008-02-26
[37]
웹사이트
Re: write barrier over device mapper supported or not?
http://oss.sgi.com/a[...]
Oss.sgi.com
2013-06-22
[38]
웹사이트
XFS and zeroed files
http://madduck.net/b[...]
Madduck.net
2008-07-11
[39]
웹사이트
Barrier Sync
https://web.archive.[...]
forums.opensuse.org
2007-03
[40]
웹사이트
Re: Proposal for "proper" durable fsync() and fdatasync()
http://www.mail-arch[...]
Mail-archive.com
2008-02-26
[41]
문서
I/O Barriers, as of kernel version 2.6.31
http://www.mjmwired.[...]
Mjmwired.net
2013-06-22
[42]
웹사이트
Virtualization and IO Modes = Extra Complexity
http://www.mysqlperf[...]
Mysqlperformanceblog.com
2011-03-21
[43]
웹사이트
SSD, XFS, LVM, fsync, write cache, barrier and lost transactions
http://www.mysqlperf[...]
Mysqlperformanceblog.com
2009-03-02
[44]
웹사이트
10 Highlights of Jon Corbet's Linux Kernel Report
https://www.linux.co[...]
2015-02-19
[45]
웹사이트
"Theodore Ts'o": Proposal and plan for ext2/3 future development work
https://lkml.org/lkm[...]
LKML
2013-06-22
[46]
웹사이트
Panelists ponder the kernel at Linux Collaboration Summit
https://arstechnica.[...]
2009-08-22
[47]
간행물
Re: reiser4 for 2.6.27-rc1
https://lkml.org/lkm[...]
2010-12-31
[48]
웹사이트
LKML: Jan Kara: [GIT PULL] Ext3 removal, quota & udf fixes
https://lkml.org/lkm[...]
2015-12-26
[49]
문서
Speeding up ext3 filesystems
[50]
문서
Common threads: Advanced filesystem implementor's guide, Part 8
[51]
문서
Post to the ext3-users mailing list
ext3-users mailing list post
[52]
문서
Shake
Vleu.net
[53]
문서
Index of /apps/defrag
[54]
문서
RE: searching for ext3 defrag/file move program
[55]
문서
filesystems.html
http://www.tldp.org/[...]
[56]
문서
Documentation/filesystems/ext2.txt
Linux kernel source documentation
[57]
문서
Re: Frequent metadata corruption with ext3 + hard power-off
[58]
문서
inode의 최대 개수는 파일 시스템 생성시 결정된다 (즉, 파일 및 디렉터리의 최대 개수). V는 바이트 단위의 볼륨 사이즈를 말하며, inode의 디폴트 개수는 V/213이고 (또는 블록의 개수, 어느 것이든 해당 개수보다 작다), V/223가 최솟값이다. 디폴트 값은 대부분의 응용 프로그램에서 충분한 값이다. 한 디렉터리가 포함하는 하위 디렉터리의 최대 개수는 32000으로 고정된다.
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com