ext3

ext3
유전자는 EXT3(유전자)를 참조한다.
ext3
개발자스티븐 트위디
풀네임세 번째 확장 파일 시스템
소개했다2001년 11월 Linux 2.4.15 탑재
파티션 식별자0x83(MBR)
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7(GPT)
구조물들
디렉토리 내용테이블, dir_index가 네이블로 되어 있는 해시 B-tree
파일 할당비트맵(사용 가능한 공간), 테이블(표준)
불량 블록테이블
한계
최대 볼륨 크기4 TiB – 32 TiB
최대 파일 크기16 GiB –2 TiB
최대 파일 수변수, 생성[1] 시 할당됨
최대 파일 이름 길이255 바이트
파일 이름에 허용되는 문자NUL('\0') 및 '/'을 제외한 모든 바이트
특징들
기록된 날짜변경(mtime), 속성 변경(ctime), 액세스(atime)
날짜 범위1901년 12월 14일 ~ 2038년 1월 18일
날짜 해결1초
특성allow-delete, append-only, h-tree(디렉토리), 불변, 저널, 무시간, 무시간, 보안 삭제, 동기 쓰기, top(디렉토리)
파일 시스템 권한Unix 권한, ACL 및 임의의 보안 속성(Linux 2.6 이후)
투과적 압축아니요.
투과적 암호화아니요(블록 디바이스레벨로 제공)
데이터 중복 배제아니요.
다른.
지원되는 운영 체제Linux, BSD, ReactOS,[2] Windows (IFS 경유)

ext3 또는 세 번째 확장 파일 시스템은 Linux 커널에서 일반적으로 사용되는 저널 형식의 파일 시스템입니다.이것은 많은 인기 있는 Linux 배포판의 기본 파일 시스템이었습니다.Stephen Twedie는 1998년 논문에 "Journing the Linux ext2fs Filesystem"에서 ext2 확장 작업을 하고 있음을 처음 밝혔고, 이후 1999년 2월에 커널 메일링 목록을 게시했습니다.파일 시스템은 2001년 11월에 메인라인 Linux 커널과 [3][4][5]2.4.15 이후 통합되었습니다.ext2에 비해 가장 큰 장점은 저널링입니다.이것에 의해, 신뢰성이 향상해, 부정한 셧다운 후에 파일 시스템을 확인할 필요가 없어집니다.그 후계자는 ext4 [6]입니다.

이점

ext3의 성능(속도)은 ext4, JFS, ReiserFS 및 XFS와 같은 경쟁사의 Linux 파일 시스템에 비해 매력적이지 않지만 ext3는 데이터를 백업 및 복원하지 않고도 ext2에서 인플레이스 업그레이드를 수행할 수 있다는 점에서 상당한 이점이 있습니다.벤치마크에 따르면 ext3는 Reiser보다 CPU 소비 전력도 적습니다.FS 및 XFS.[7][8]또한 비교적 단순하고 테스트 기반이 [9][10]넓기 때문에 다른 Linux 파일 시스템보다 안전하다고 간주됩니다.

ext3는 ext2에 다음 기능을 추가합니다.

  • 일지
  • 온라인 파일 시스템 증가
  • 대형[11] 디렉토리용 HTree 색인화

이러한 기능이 없으면 ext3 파일시스템도 유효한 ext2 파일시스템이 됩니다이러한 상황에서 ext2 파일 시스템을 유지보수 및 복구하기 위한 충분한 테스트와 성숙한 파일 시스템 유지보수 유틸리티를 ext3에서도 큰 변경 없이 사용할 수 있게 되었습니다.ext2 및 ext3 파일시스템은 fsck 툴을 포함한 동일한 표준 유틸리티 세트 e2fsprogs를 공유합니다.또, 밀접한 관계에 의해, 2개의 파일 시스템(모두 ext3 로의 전송과 ext2 로의 역방향)간의 변환도 간단하게 실시할 수 있습니다.

ext3에는 동적 inode 할당 및 익스텐트와 같은 "현대적" 파일 시스템 기능이 없습니다.이 상황은 때때로 단점이 될 수 있지만 복구 가능성에 있어서는 상당한 이점이 있습니다.파일 시스템 메타데이터는 모두 고정되고 잘 알려진 위치에 있으며 데이터 구조에는 용장성이 있습니다.심각한 데이터 손상의 경우 ext2 또는 ext3는 복구할 수 있지만 트리 기반 파일 시스템은 복구할 수 없습니다.

크기 제한

ext3의 최대 블록 수는 2입니다32.블록 크기는 파일 최대 수와 파일 [12]시스템의 최대 크기에 영향을 미치며 달라질 수 있습니다.

블록 크기 최대치
파일 크기		 최대치
파일 시스템 크기
1 KiB 16 GiB 2 TiB
2 KiB 256 GiB 8 TiB
4 KiB 2 TiB 16 TiB
8KiB[limits 1] 2 TiB 32 TiB
  1. ^ Linux의 경우 8KiB 블록 크기는 Alpha와 같이 8KiB 페이지를 허용하는 아키텍처에서만 사용할 수 있습니다.

저널링 레벨

ext3의 Linux 구현에서는 다음 3가지 수준의 저널링을 사용할 수 있습니다.

저널(최저위험)
메타데이터 및 파일 내용은 모두 메인 파일 시스템에 커밋되기 전에 저널에 기입된다.저널은 디스크에서 비교적 연속적이기 때문에 저널에 충분한 공간이 있으면 성능이 향상될 수 있습니다.데이터를 저널에 한 [13]번, 파일 시스템의 주요 부분에 한 번 두 번 써야 하기 때문에 성능이 저하되는 경우도 있습니다.
주문 완료(중위험)
메타데이터만 저널링되고 파일 내용은 저널링되지 않지만 관련 메타데이터가 저널에 커밋된 것으로 표시되기 전에 파일 내용이 디스크에 기록되도록 보장합니다.이것은 많은 Linux 디스트리뷰션에서 기본입니다.파일을 쓰거나 추가하는 동안 정전이나 커널 패닉이 발생하면 저널에 새 파일 또는 추가된 데이터가 "커밋되지 않았음"이 나타나므로 정리 프로세스에 의해 삭제됩니다.(따라서 새로운 파일이 추가되고 "journaled" 수준과 동일한 수준의 무결성 보호가 제공됩니다.)그러나 파일의 원래 버전이 저장되지 않기 때문에 덮어쓰는 파일이 손상될 수 있습니다.따라서 둘 중 하나를 복원하기에 충분한 정보가 없는 상태에서 새 파일과 오래된 파일 사이의 중간 상태로 끝날 수 있습니다(새로운 데이터는 디스크에 완전히 저장되지 않으며 이전 데이터는 아무데도 저장되지 않습니다).게다가 기입 [13][14]순서는 디스크의 하드웨어에 의존하기 때문에, 중간 상태는 낡은 데이터와 새로운 데이터를 분산시킬 가능성이 있습니다.
라이트백(리스크가 가장 높음)
메타데이터만 저널링되고 파일 내용은 저널링되지 않습니다.내용은 저널 업데이트 전 또는 후에 기록될 수 있습니다.그 결과 크래시 직전에 수정된 파일이 손상될 수 있습니다.예를 들어, 첨부되는 파일이 저널에 실제 크기보다 큰 것으로 표시되어 마지막에 가비지가 발생할 수 있습니다.저널 복구 후 이전 버전의 파일도 예기치 않게 나타날 수 있습니다.많은 경우 데이터와 저널 간의 동기화가 더 빠릅니다.JFS는 이 수준의 저널링을 사용하지만, 재기동시에 기입되지 않은 데이터로 인한 「쓰레기」가 제로인 것을 확인합니다.XFS는 이 형식의 저널링도 사용합니다.

이 3가지 모드에서 파일 시스템의 내부 구조는 크래시 후에도 일관성이 보장됩니다.어느 경우든 시스템이 크래쉬 했을 때 변경되고 있던 파일 또는 디렉토리의 데이터 내용만 영향을 받습니다.나머지는 복구 후에도 그대로 유지됩니다.

단점들

기능

ext3는 이전 ext2와의 하위 호환성을 목표로 하기 때문에 많은 온디스크 구조가 ext2와 유사합니다.따라서 ext3에는 익스텐트, inode의 동적 할당, 블록 서브 [15]할당 등의 최신 기능이 없습니다.inode는 최대 32,000개의 링크를 가질 수 있기 때문에 디렉토리에는 최대 398개의 서브디렉토리가 있습니다(각 다이렉트서브디렉토리는 ".." [16]참조의 부모폴더 inode 링크카운터를 증가시킵니다.

ext3에서는 대부분의 최신 Linux 파일 시스템과 마찬가지로 파일 시스템이 [6]쓰기용으로 마운트되어 있는 동안에는 시스템 도구 "fsck"를 사용하지 마십시오.읽기/쓰기 모드로 이미 마운트된 파일 시스템을 확인하려고 하면 파일 시스템 메타데이터의 불일치가 검출될 가능성이 매우 높습니다.파일 시스템 메타데이터가 변경되고 fsck가 변경을 적용하여 "일관성이 없는" 메타데이터를 "일관성이 없는" 상태로 만들려는 경우, 불일치를 "수정"하려고 하면 파일 시스템이 손상됩니다.

조각 모음

파일 시스템 수준에서 작동하는 온라인 ext3 조각 모음 도구는 없습니다.오프라인 ext2 조각 모음이 있습니다.e2defrag.하지만,e2defrag는 파일 시스템에서 켜져 있는 기능 비트에 따라 데이터가 파괴될 수 있습니다.새로운 ext3 [17]기능의 많은 처리 방법을 모릅니다.

Shake 및 [19][20]deflag와 같은[18] 사용자 공간 조각 모음 도구가 있습니다.Shake는 파일 전체의 공간을 1개의 작업으로 할당함으로써 동작합니다.이 경우 일반적으로 할당자가 연속된 디스크 공간을 찾습니다.동시에 사용하는 파일이 있으면 Shake는 서로 옆에 쓰려고 합니다.조각 모음은 각 파일을 복사하는 방식으로 작동합니다.그러나 이 전략은 파일 시스템에 사용 가능한 공간이 충분한 경우에만 작동합니다.ext3에는 진정한 디플래그 툴이 없습니다.[21]

그러나 Linux System Administrator Guide에 기술되어 있듯이 "현대 Linux 파일 시스템은 연속된 섹터에 저장할 수 없는 경우에도 파일 내의 모든 블록을 서로 가깝게 유지함으로써 조각화를 최소한으로 유지합니다.ext3와 같은 일부 파일 시스템은 파일 내의 다른 블록에 가장 가까운 빈 블록을 효과적으로 할당합니다.따라서 Linux 시스템에서는 플래그멘테이션에 대해 걱정할 필요가 없습니다."[22]

ext3는 파일 플래그멘테이션에 대한 내성이 있지만 ext3는 시간이 지남에 따라 또는 큰 [23][24]파일을 천천히 쓰는 등의 특정 사용 패턴에 따라 분할될 수 있습니다.따라서 ext4(ext3의 후속 버전)는 온라인 파일 시스템 조각 모음 유틸리티 e4defrag를[25] 가지고 있으며 현재 extent(연속 파일 영역)를 지원합니다.

삭제 취소

ext3는 삭제된 파일의 복구를 지원하지 않습니다.ext3 드라이버는 크래시 안전을 위해 파일[26] inode를 삭제함으로써 파일을 적극적으로 삭제합니다.

파일 시스템 저널 분석을 사용하여 삭제되거나 손실된 파일을 복구하기 위한 몇 가지 기술[27] 및 무료 소프트웨어도[28][29] 있지만 특정 파일 복구는 보장되지 않습니다.

압축

e3syslog는[30] 투과적인 압축을 수행하는 ext3의 비공식 패치입니다.그것은 e2compr의 직접 항구이며, 아직 더 많은 개발이 필요하다.업스트림[citation needed] 커널을 사용하여 컴파일 및 부팅이 가능하지만 저널링은 아직 구현되지 않았습니다.

스냅샷 지원 부족

많은 최신 파일 시스템과 달리 ext3에는 스냅샷이 기본적으로 지원되지 않으므로 임의의 시간에 파일 시스템 상태를 빠르게 캡처할 수 있습니다.대신 Linux LVM에서 제공하는 공간 효율이 낮은 볼륨 레벨 스냅샷에 의존합니다.Next3 파일 시스템은 스냅샷 지원을 제공하는 ext3의 수정 버전이지만 ext3 온디스크 [31]포맷과의 호환성을 유지합니다.

저널에 체크섬 없음

ext3는 저널에 쓸 때 체크섬을 수행하지 않습니다.추가 캐시가 있는 스토리지 디바이스에서 barrier=1이 마운트 옵션(/etc/fstab에서)으로 활성화되지 않고 하드웨어가 잘못된 쓰기 캐싱을 수행하는 경우 충돌 [32][33][34]시 심각한 파일 시스템 손상 위험이 있습니다.이는 쓰기 캐시가 있는 스토리지 장치가 데이터가 (휘발성) 캐시에 기록되었더라도 데이터가 완전히 기록되었음을 시스템에 보고하기 때문입니다.

하드 디스크 쓰기가 잘못된 순서로 이루어진 경우(쓰기 속도를 상각하기 위해 최신 하드 디스크 캐싱 쓰기 때문에), 다른 관련 블록이 기록되기 전에 트랜잭션의 커밋 블록이 작성될 수 있습니다.다른 블록이 기입되기 전에 전원 장애나 회복 불가능한 크래시가 발생했을 경우는, 시스템을 재기동할 필요가 있습니다.재부팅 시 파일 시스템은 로그를 정상적으로 재생하고 "winners"(위의 비활성 트랜잭션을 포함하여 유효한 커밋 블록으로 태그가 지정된 커밋 블록이 있는 트랜잭션)를 재생합니다.따라서 위의 완료되지 않은 디스크 쓰기가 진행되지만 손상된 저널 데이터가 사용됩니다.따라서 파일 시스템은 저널을 재생하는 동안 일반 데이터를 손상된 데이터로 잘못 덮어씁니다.체크섬을 사용하여 "위장 승자" 트랜잭션 블록에 상호 체크섬이 태그되어 있었다면 파일 시스템이 더 잘 알고 손상된 데이터를 디스크에 재생하지 않았을 수 있습니다.저널 체크섬이 [35]ext4에 추가되었습니다.

디바이스 매퍼 인터페이스(소프트웨어 RAID 및 LVM 구현 포함)를 통과하는 파일 시스템은 장벽을 지원하지 않을 수 있으며 마운트 옵션을 사용할 [36][37]경우 경고가 발생합니다.또한 일부 디스크는 장벽 작동에 필요한 쓰기 캐시 플러시 확장을 제대로 구현하지 않아 유사한 경고가 [38]발생합니다.장벽이 지원되지 않거나 실용적이지 않은 상황에서는 디스크의 쓰기 캐시를 끄고data=journal마운트 옵션.[32]장벽을 사용할 수 있는 경우에도 디스크의 쓰기 캐시를 해제해야 할 수 있습니다.

데이터베이스와 같은 애플리케이션은 fsync() 호출이 보류 중인 쓰기를 디스크에 플러시할 것으로 예상하며, 장벽 구현이 해당 [39]호출에 응답하여 드라이브의 쓰기 캐시를 항상 지우는 것은 아닙니다.드라이브 장애와 [40]같은 이벤트 중 오류 처리와 관련된 장벽 구현에도 잠재적인 문제가 있습니다.또한 일부 가상화 기술이 fsync 명령 또는 flush [41]명령을 게스트 운영 체제에서 기본 디바이스(파일, 볼륨, 디스크)로 제대로 전송하지 못하는 경우도 있습니다.마찬가지로 일부 하드 디스크 또는 컨트롤러는 캐시 플러시를 잘못 구현하거나 전혀 구현하지 않지만 캐시 플러시가 지원되고 있음을 알리고 사용 [42]시 오류를 반환하지 않습니다.fsync 및 쓰기 캐시 처리를 잘못 처리하는 방법은 매우 많습니다.개개의 컴포넌트가 얼마나 신뢰성이 있다고 생각되는지에 관계없이 캐시 플러시는 명시적으로 테스트되지 않는 한 동작하지 않는다고 가정하는 것이 안전합니다.

날짜 스탬프 제한으로 인한 근일 소멸

Ext3는 파일 헤더에 4바이트를 사용하여 날짜를 UNIX 시간으로 저장합니다.32비트는 2038년 1월 18일 이후 파일 처리를 계속하기에 충분한 범위를 제공하지 않습니다.2038년 문제.[43]

ext4

fsck 시간은 inode 수에 의존합니다(ext3 대 ext4).
주요 기사: ext4

2006년 6월 28일 ext3의 [44]주요 개발자인 Theodore Tso는 ext4라는 확장 버전을 발표했습니다.2008년 10월 11일, ext4를 안정된 코드로 마크한 패치가 Linux 2.6.28 소스 코드 저장소에 병합되어 개발 단계가 종료되었습니다.2008년에 Tso는 ext4가 ext3보다 훨씬 빠른 등의 기능을 개선했지만 큰 진보는 아니며 오래된 기술을 사용하며 임시방편이라고 말했습니다.Tso는 Btrfs가 "확장성, 신뢰성 및 관리의 용이성을 향상시키고 있기 때문에" Btrfs가 더 나은 방향이라고 생각합니다.[45]Btrfs는 또한 "reiser 3/4과 동일한 디자인 아이디어 다수"[46]를 가지고 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ inode의 최대수(즉, 파일 및 디렉토리의 최대수)는, 파일 시스템 작성시에 설정됩니다.V가 볼륨 크기(바이트)인 경우 기본 inode 수는 V/2(또는 블록 수 중 더 작은 쪽)로 지정되고 최소값은 V/2로1323 지정됩니다.대부분의 어플리케이션에서는 디폴트로 충분하다고 생각되었습니다.1 개의 디렉토리내의 서브 디렉토리의 최대수는 32000 으로 고정됩니다.
  2. ^ "ReactOS 0.4.2 Released". reactos.org. Retrieved 17 August 2016.
  3. ^ Stephen C. Tweedie (May 1998). "Journaling the Linux ext2fs Filesystem" (PDF). Proceedings of the 4th Annual LinuxExpo, Durham, NC. Retrieved 2007-06-23.
  4. ^ Stephen C. Tweedie (February 17, 1999). "Re: fsync on large files". Linux kernel mailing list.
  5. ^ Rob Radez (November 23, 2001). "2.4.15-final". Linux kernel mailing list.
  6. ^ a b "Chapter 6. The Ext4 File System Red Hat Enterprise Linux 6".
  7. ^ Piszcz, Justin. "Benchmarking Filesystems Part II". Linux Gazette (122).
  8. ^ Ivers, Hans. "Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch". Archived from the original on 2008-09-13. Retrieved 2010-11-03. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  9. ^ Smith, Roderick W. (2003-10-09). "Introduction to Linux filesystems and files". Linux.com. Archived from the original on August 30, 2011.
  10. ^ Trageser, James (2010-04-23). "Which Linux filesystem to choose for your PC? Ext2, Ext3, Ext4, ReiserFS (Reiser3), Reiser4, XFS, Btrfs".
  11. ^ Cao, Mingming. "Directory indexing". Features found in Linux 2.6.
  12. ^ Matthew Wilcox. "Documentation/filesystems/ext2.txt". Linux kernel source documentation.
  13. ^ a b Daniel Robbins (2001-12-01). "Common threads: Advanced filesystem implementor's guide, Part 8". IBM developerWorks. Archived from the original on 2007-10-13.
  14. ^ 호기심 많은 온루커: ext3 파일 시스템 고속화.에부라인blogspot.com (2007-01-09)2013-06-22에 회수.
  15. ^ Radez, Rob (2005). "Extents, Delayed Allocation". future of ext3.
  16. ^ Robert Nichols (2007-04-03) 관련: 몇 개의 서브디렉토리가 있습니까?linux.derkeiler.com
  17. ^ Andreas Dilger. "Post to the ext3-users mailing list". ext3-users mailing list post.
  18. ^ 흔들어요. Vleu.net2013-06-22에 회수.
  19. ^ 조각 모음은 셸로 작성되었습니다.Ck.kolivas.org (2012-08-19)2013-06-22에 회수.
  20. ^ Python으로 작성된 조각 모음입니다.Bazaar.launchpad.net 를 참조해 주세요.2013-06-22에 회수.
  21. ^ RE: ext3 조각 모음/파일 이동 프로그램을 검색합니다.Redhat.com(2005-03-04)2013-06-22에 회수.
  22. ^ 5.10. 파일 시스템Tldp.org (2002-11-09)2013-06-22에 회수.
  23. ^ "#849 closed Enhancement (fixed) - preallocation to prevent fragmentation". trac.transmissionbt.com. The default Ubuntu filesystem ("ext3") will fragment large (>1GB), slowly growing files (<1MB/s)
  24. ^ Oliver Diedrich (27 October 2008). "Tuning the Linux file system Ext3". We found heavily fragmented free areas on an intensively used IMAP server which stores all its emails in individual files – although more than 900 GB of the total disk space of 1.4 TB were still available
  25. ^ Ext4 – Linux 커널 신기능Kernelnewbies.org (2011-05-19)2013-06-22에 회수.
  26. ^ Linux ext3에 관한 FAQ.Batleth.sapienti-sat.org 를 참조해 주세요.2013-06-22에 회수.
  27. ^ HOWTO는 삭제된 파일을 ext3 파일 시스템에서 복구합니다.Wayback Machine Xs4all.nl(2008-02-07).2013-06-22에 회수.
  28. ^ PhotoRec – GPL'd 파일 리커버리Cgsecurity.org 를 참조해 주세요.2013-06-22에 회수.
  29. ^ UFS Explorer Standard Recovery 버전 4.Ufsexplorer.com 를 참조해 주세요.2013-06-22에 회수.
  30. ^ e3gl: ext3 압축.Sourceforge.net 를 참조해 주세요.2013-06-22에 회수.
  31. ^ Jonathan Corbet. "The Next3 filesystem". LWN.
  32. ^ a b 참조: ext3 + 하드 전원 끄기 시 메타데이터가 자주 파손됩니다.Archives.free.net.ph 를 참조해 주세요.2013-06-22에 회수.
  33. ^ 참조: ext3 + 하드 전원 끄기 시 메타데이터가 자주 파손됩니다.Archives.free.net.ph 를 참조해 주세요.2013-06-22에 회수.
  34. ^ Red Hat Enterprise Linux, 20장. 기입 장벽
  35. ^ ext4: 저널 체크섬 기능을 추가합니다.Article.gmane.org (2008-02-26)2013-06-22에 회수.
  36. ^ 참조: 디바이스 매퍼에 대한 쓰기 장벽 지원 여부Oss.sgi.com 를 참조해 주세요.2013-06-22에 회수.
  37. ^ XFS 및 제로 파일 웨이백 머신에 2008-04-30 아카이브.Madduck.net (2008-07-11)2013-06-22에 회수.
  38. ^ 장벽 동기. forums.opensuse.org (2007년 3월)
  39. ^ 참조: "적절한" 내구 fsync() 및 fdataasync() 제안.Mail-archive.com (2008-02-26)2013-06-22에 회수.
  40. ^ 커널 버전 2.6.31 이후 I/O 장벽Mjmwired.net 를 참조해 주세요.2013-06-22에 회수.
  41. ^ 가상화 및 IO 모드 = 복잡성 증가.Mysqlperformanceblog.com (2011-03-21)2013-06-22에 회수.
  42. ^ SSD, XFS, LVM, fsync, 쓰기 캐시, 장벽 및 트랜잭션 손실.Mysqlperformanceblog.com (2009-03-02)2013-06-22에 회수.
  43. ^ Clark, Libby (19 February 2015). "10 Highlights of Jon Corbet's Linux Kernel Report". Retrieved 2019-01-26.
  44. ^ Theodore Ts'o: 향후 개발 작업의 연장 2/3 제안 및 계획.LKML. 2013-06-22에 회수.
  45. ^ Ryan Paul (2009-04-13). "Panelists ponder the kernel at Linux Collaboration Summit". Ars Technica. Retrieved 2009-08-22.
  46. ^ Theodore Ts'o (2008-08-01). "Re: reiser4 for 2.6.27-rc1". linux-kernel (Mailing list). Retrieved 2010-12-31.

외부 링크