ext2 파일시스템 디자인과 구현-I번역 : 배철수/리눅스월드 발행인
이 글의 원문은 http://e2fsprogs.sourceforge.net/ext2intro.html 에 있다.
서문(Introduction)
리눅스는 386 피시에서 가동하는 유닉스 클론 운영체제이다. 리눅스는 처음에는 미닉스(Minix) 운영체제의 확장판으로 구현되었다. 그래서 첫 번 버전은 미닉스 파일 시스템만을 지원했다.
미닉스 파일시스템은 두 개의 심각한 약점을 갖고 있다. 즉 블록 주소가 16 비트 정수로 저장된다. 그래서 파일 시스템의 최대 크기가 64메가 바이트로 제한된다. 그리고 디렉토리 입력 항목의 크기가 고정되어 있어서 최대 파일 네임 길이가 14자이다.
우리는 표준 리눅스 커널에 포함된 두 개의 새로운 파일 시스템을 설계 및 구현하였다. 이들 파일 시스템은 각각 ``Extended File System’’ (Ext fs) 과 ``Second Extended File System’’ (Ext2 fs) 라고 불리는데 이러한 제약을 제거하고 새로운 기능을 추가했다.
이 문서에서 우리는 리눅스 파일 시스템의 역사를 설명한다. 우리는 간단하게 유닉스 파일 시스템에 구현되어진 기본적인 개념을 소개한다. 우리는 리눅스에서 버츄얼 파일 시스템(Virtual File System) 계층의 구현을 보여주고 EXT2 파일시스템 커널코드와 사용자 모드 도구들을 상세히 설명한다. 끝으로 리눅스와 BSD파일시스템에서 행해진 성능측정을 보여주고서 EXT2파일시스템의 현재상태와 앞으로의 방향을 보여주는 것으로 마치겠다.
1. 리눅스 파일 시스템의 역사(History of Linux filesystems)
초창기에 리눅스는 미닉스 운영 체제하에서 교차 개발되었다. 새로운 파일 시스템을 디자인하는 것 보다는 두 시스템 사이에서 디스크를 공유하는게 보다 쉬웠다. 그래서 리누스 토발즈는 리눅스에 미닉스 파일 시스템 지원을 구현하기로 결정했다. 미닉스 파일 시스템은 효율적이었고 비교적 버그가 없는 소프트웨어였다.
그러나, 미닉스 파일 시스템의 디자인상의 제약은 매우 심각했으므로 사람들은 리눅스에서 새로운 파일 시스템을 검토했고 작업을 시작했다.
새로운 파일시스템을 리눅스 커널에 추가하는 것을 쉽게 하기 위해서, 버츄얼 파일 시스템 계층(Virtual File System (VFS) layer)이 개발되었다. VFS 계층은 초기에는 Chris Provenzano 의해 씌여졌다. 그리고 나중에 리누스 토발즈에 의해 고쳐져서 리눅스 커널에 통합되었다. 이는 버츄얼 파일 시스템 설명을 참고하기 바란다.
커널에 VFS가 통합된 후에 1992년 4월에 “Extended File System” 이라고 불리는 새로운 파일 시스템이 구현되어 Linux 0.96c 에 추가되었다. 이 새 파일 시스템은 미닉스 파일 시스템의 두 제약을 제거했다. 즉 최대 파일시스템 크기는 2 기가 바이트로 최대파일네임 길이는 255자였다. 이는 미닉스 파일 시스템에 비해 훨씬 개선된 것이나, 아직도 몇 가지 문제점이 남아있었다.
즉, 별도 억세스(separate access), 아이노드 수정 (inode modification), 데이터수정 타임스탬프(data modification timestamps )에 대한 지원이 없었다.
파일시스템은 프리블록 및 아이노드의 트랙을 추적하기 위해 연결리스트를 사용했다. 이는 낮은 성능을 초래했다. 미 사용 블록과 아이노드를 파악하기 위해 링크드 리스트(linked lists)를 사용했고 이는 낮은 성능을 초래했다. 즉 파일시스템이 사용됨에 따라 리스트는 정렬이 되지 않으므로 파일시스템은 여기저기 흩어진다.
이러한 문제점에 대처하기 위해 93년 1월에 두개의 새로운 파일시스템의 알파버전이 발되었다. 즉 XIA 파일시스템과 ext2 파일시스템이다. XIA 파일시스템은 미닉스 파일시스템 커널 코드에 크게 의존했고 여기에 몇 가지 기능만 개선했다. 기본적으로 긴 파일이름과 큰 파티션 및 세 타임스탬프를 지원했다. 반면 ext2 fs는 ext fs 코드에 기초를 두었으나 상당 부분을 고쳐 썼고 많은 기능을 추가했다. 또한 기능 개선을 염두에 두고 미래의 개량에 대한 여지를 남겨 두었다. 이는 The Second Extended File System에서 설명한다.
두개의 새 파일 시스템이 발표됐을 때 그들은 기본적으로 동일한 기능을 제공했다. 간편한 디자인 때문에 XIA파일시스템이 EXT2 파일시스템보다 안정적이었다. 파일시스템이 보다 널리 사용되기 시작함에 따라 EXT2 파일시스템의 버그가 수정되었고 많은 개선과 새로운 기능이 추가되었다. 이제 EXT2 FS는 이제 매우 안정적이고 리눅스 파일 시스템의 표준이 되었다.
아래 표는 여러 파일 시스템간에 기능을 비교해준다.
|
Minix FS |
Ext FS |
Ext2 FS |
Xia FS |
최대 파일시스템 크기 |
64 MB |
2 GB |
4 TB |
2 GB |
최대 파일 크기 |
64 MB |
2 GB |
2 GB |
64 MB |
최대 파일네임 길이 |
16/30 c |
255 c |
255 c |
248 c |
3 타임스탬프 지원 |
No |
No |
Yes |
Yes |
확장성 |
No |
No |
Yes |
No |
가변 블록 사이즈 |
No |
No |
Yes |
No |
지원 |
Yes |
No |
Yes |
? |
2. 기본 파일 시스템 개념(Basic File System Concepts)
모든 리눅스 파일 시스템은 유닉스 운영 체재로부터 유래된 몇 가지 공통된 기본개념들을 구현하고 있다. 파일은 아이노드에 의해 표현되고 디렉토리는 단순히 여러 개의 엔트리를 갖는 파일에 불과하다. 장치는 특별한 파일에 대한 입출력(I/O)요청에 의해 접근되어질 수 있다.
2.1 아이노드(Inodes)
각각의 파일은 아이노드라고 불리는 구조에 의해서 표현된다. 각 아이노드는 파일에 대한 정보를 담고 있다. 즉 파일형태, 접근권한, 소유자, 타임스탬프, 크기, 데이터블록 포인터 등이다.파일에 할당된 데이터 블록의 주소는 아이노드에 저장된다. 사용자가 파일에 대해 입출력(I/O)를 요청하면 커널 코드는 블록넘버에서 오프셋을 찾아내서 이 숫자를 블록 주소 테이블에서의 인덱스로 사용하고 물리적인 블록을 읽거나 쓴다.
아래 그림이 Inode 구조를 보여준다.
2.2 디렉토리(Directories)
디렉토리는 계층구조로 구성되어 있다. 각각의 디렉토리는 파일과 서브디렉토리를 포함하고 있다.
디렉토리는 특별한 형태의 파일로 표현된다. 실제로 디렉토리는 여러 개의 엔트리를 갖는 파일이다. 각 엔트리는 한 개의 아이노드 넘버와 한 개의 파일이름을 갖는다. 어느 프로세스가 패스네임을 사용할 때 커널 코드는 해당 아이노드 넘버를 알기 위해 디렉토리를 설치한다. 이름이 아이노드 넘버로 변환되어졌을 때 아이노드는 메모리로 올려지고 이후의 요청에 사용된다. 아래 그림은 디렉토리를 보여준다.
2.3 링크(Links)
유닉스 파일 시스템은 링크라는 개념을 도입하고 있다. 여러 개의 이름이 하나의 아이노드에 연결될 수 있다. 아이노드는 파일과 관련된 번호를 포함하는 필드를 갖고 있다. 링크를 추가하는 것은 단순히 디렉토리 엔트리를 만드는 것이다. 그 아이노드 번호는 아이노드를 가리키고 아이노드에서 링크 카운트를 증가시킨다. 링크가 지워질 때, 즉 사용자가 rm 커맨드로 파일을 삭제하면 커널은 링크 카운트를 감소시키고 만약 이 카운트가 0이되면 아이노드는 해제된다.
이러한 형태의 링크는 하드링크라고 불리운다. 그리고 오직 동일한 파일 시스템 내에서만 사용될 수 있다. 파일 시스템이 다른 경우에 하드 링크를 만드는 것은 불가능하다. 하드 링크는 오직 파일에서만 가능하고 디렉토리 하드 링크는 디렉토리 구조에 있어서 순환을 방지하기 위해 만들 수 없다.
다른 종류의 링크가 유닉스 파일시스템에 존재한다. 심볼릭 링크는 단순히 파일 이름을 갖고 있는 파일이다. 커널이 패스네임/아이노드 변환시에 심볼릭 링크를 발견하게 되면 커널은 링크이름을 즉 목적파일의 이름을 그 내용으로 대치한다. 그리고서 패스네임 찾기를 재개한다. 심볼릭 링크는 아이노드에 대한 포인터를 갖고 있지 않으므로 다른 파일시스템에 심볼릭 링크를 만드는게 가능하다. 심볼릭 링크는 어떤 형태의 파일에 대해서도 가능하며 존재하지 않는 파일에 대해서도 가능하다. 심볼릭 링크는 하드 링크가 갖고 있는 제한을 갖고 있지 않으므로 매우 유용하다. 그러나 그들은 아이노드와 데이터 블록을 위한 약간의 디스크 공간을 사용하며 커널이 심볼릭 링크를 만나게 되면 이름 찾기를 다시 해야 하기 때문에 패스네임을 아이노드로 변환하는 과정에서 약간의 오버헤드가 발생한다.
2.4 장치 파일(Device special files)
유닉스 계열 운영체제에서 장치는 특수 파일에 의해서 접근될 수 있다. 장치파일은 파일시스템에서 어떤 공간을 사용하지는 않는다. 이들은 단지 장치드라이버의 접근점에 불과하다.
두 가지 형태의 장치특수파일이 존재한다. 캐릭터와 블록 스페셜 파일이다. 전자는 캐릭터 모드로 입출력 동작을 허용하고 후자는 버퍼캐시 기능을 통해 블록모드로 데이터가 쓰여져야 한다. 특수파일에 대해서 입출력(I/O)요청이 일어날 경우 이들은 가상 장치 드라이버((pseudo) device driver)로 포워딩된다. 특수파일은 장치형태를 구별해주는 메이저넘버와 각각의 유니트를 구별해주는 마이너넘버로 표현된다.
3.버츄얼파일시스템(The Virtual File System)
3.1 원리(Principle)
리눅스 커널은 파일에 대한 시스템 콜이 있을 때 사용되어지는 버츄얼 파일 시스템 계층을 갖고 있다. VFS는 파일과 관련 시스템 콜을 다루는 중간 계층이며 입출력을 처리하기 위해 물리적인 파일 시스템 코드에서 필요한 펑션을 부른다.
이러한 간접 메커니즘은 여러 개의 파일시스템 형태의 통합을 쉽게 하기 위해 유닉스 계열 운영체제에 흔히 사용된다.
어떤 프로세스가 파일 관련 시스템 콜을 일으킬 때 커널은 VFS에 포함된 펑션을 부른다. 이 펑션은 구조와 독립적인 조작을 실행하고 그 요청을 물리적인 파일시스템코드에 포함된 펑션으로 연결해 준다. 물리적인 파일시스템 코드가 구조에 의존하는 동작을 담당한다. 파일 시스템 코드는 장치에 대해 I/O를 요청하기 위해 버퍼 캐쉬 펑션을 사용한다.
이 구조가 아래 그림에 설명되어 있다.
3.2 구조 (The VFS structure)
VFS는 모든 파일 시스템이 필요로 하는 일련의 펑션을 정의하고 있다. 이러한 인터페이스는 세 종류 대상과 관련된 일련의 동작으로 구성된다. 즉 파일시스템, 아이노드, 열린 파일이다.
VFS는 커널에서 지원하는 파일시스템 타입을 알고 있다. 이는 커널 구성 동안에 만들어 지는 테이블을 사용한다. 이 테이블 내의 각 엔트리가 하나의 파일 시스템 타입을 정의한다. 즉 파일시스템 타입의 이름과 펑션에 대한 포인터이다.
어떤 파일 시스템이 마운트 될 때 그에 맞는 마운트 펑션이 불려 진다. 이 펑션이 디스크의 슈퍼블록을 읽는 것을 담당하며, 내부 변수를 초기화하고 vfs에 마운트된 파일시스템 디스크립터를 돌려 준다. 파일시스템이 마운트 된 후에 vfs 펑션은 물리적인 파일시스템 루틴을 접근하는데 이 디스크립터를 사용한다.
마운트된 파일시스템 디스크립터는 모든 파일시스템 타입에 공통된 몇 가지의 데이터를 포함한다. 물리적 파일시스템 커널코드에 의해 제공되는 펑션에 대한 포인터와 물리적인 파일 시스템 코드에 필요한 고유정보이다. 파일시스템 디스크립터에 포함된 펑션 포인터는 VFS가 파일 시스템 내부 루틴을 접근하는 것을 허용한다.
두 가지의 다른 디스크립터가 VFS에 의해 사용된다. 아이노드 디스크립터와 열린 파일 디스크립터이다. 각 디스크립터는 사용 중인 파일에 관련된 정보와 물리적인 파일시스템 코드에 의해 제공되는 일련의 동작을 갖고 있다. 아이노드 디스크립터는 어떤 파일에 대해서도 사용되는 펑션에 대한 포인터를 포함하는데 비해 (e.g. create, unlink) 파일 디스크립터는 열린 파일에 대해서만 작동하는 펑션에 대한 포인터를 갖는다. (e.g. read, write).
