리눅스 커널 스터디 4주차 (파일시스템과 가상 파일 시스템) (1)

파일 시스템과 가상 파일 시스템

• 리눅스가 제공하는 대표적인 객체로는 태스크와 파일이 있다.

• 태스크가 CPU를 추상화 시켜서 프로그램에게 생명을 부여한다면, 파일은 디스크를 추상화 시켜셔 프로그램에게 장소를 부여한다.

• 파일 시스템의 기본적인 개념에 대해서 살펴볼 예정이고, 모든 자원을 파일로서 취급하는 리눅스 파일 시스템 고유의 특징에 대해서 설명할 것이다.

파일 시스템 일반

• 멤리 관리 기법과 파일 시스템은 모두 기억 장치를 관리한다. 기억 장치는 메인 메모리건 하드 디스크이건 한정되어있는 자원이기 때문에 최대한 공간을 아껴서 사용 해야한다.

• 그렇기 때문에 메모리 관리 기법과 파일 시스템 모두 내부 / 외부 단편화를 최소화 하기 위해서 노력한다.

• 또한 두 기법 모두 자신만의 할당 / 해제 정책이 존재한다. 그렇다면 메모리 관리 기법과 파일 시스템간의 차이점은 무엇인가? -> 사실 차이는 이름말고는 메모리 관리 기법과 파일 시스템은 같은 소프트웨어이다.

• 결국 파일 시스템은 사용자에게 이름이라는 속성으로 접근되는 추상적인 객체인 ‘파일’이라는 개념을 제공함으로써, 영속적인 객체의 저장을 지원하는 소프트웨어인 것이다.

• 조금 추상화를 해보면, ‘이름’으로 입력을 받아서 해당 데이터를 리턴해주는 소프트웨어가 바로 파일 시스템이다.

• 그렇다면 파일 시스템은 하드 디스크에 어떤 내용을 저장해둘까? 파일 시스템이 하드 디스크에 저장하는 정보는 크게 메타 데이터와 사용자 데이터로 나뉜다. 메타 데이터는 파일의 속성 정보나 데이터 블록 인덱스 정보 등이 해당하며, 사용자가 실제 기록하려 했던 내용이 사용자 데이터에 해당한다.

• 예를 들어서 사용자가 파일을 하나 생성하고 “12월 9일 토요일 오후 3시” 라는 문자열로 구성된 약속시간을 저장한다고 가정을 하면, 파일 시스템은 디스크 블록을 하나 할당 받아서 (보통 파일 시스템에서 디스크 블록의 크기는 4KB이며 따라서 위의 문자열은 디스크 블록 한 개만으로 충분하다.) 기록해 놓으면 된다.

• 나중에 해당 파일을 읽으려면 파일 시스템이 데이터를 저장해 둔 디스크 블록 번호를 사용자가 외우고 있다가 나중에 파일시스템에게 이 번호의 데이터 블록을 읽어달라고 요청하는 것은 가능하지만 이것은 매우 귀찮다.

• 오히려 사용자는 파일이름을 통해서 추상적인 추상적인 자원인 ‘파일’을 접근하고 싶어할 것이다. 따라서 파일 시스템은 처음 데이터를 기록할 때 실제 데이터뿐만 아니라, 이 데이터를 추상적인 자원인 ‘파일’로 제공해 주기 위해서 부가적인 정보 (파일 이름, 파일의 생성시간, 실제 데이터블록을 인덱싱 하기 위한 정보)를 기록해 두어야 한다.

• 이러한 ‘이름’과 파일 정보, 인덱싱 정보를 파일 시스템의 메타 데이터라고 한다.

디스크 구조와 블록 관리 기법

• 여기서는 파일 시스템의 저장 공간의 기본 접근 단위인 디스크 블록을 관리하는 기법을 논의한다. 가장 일반적인 보조 기억 장치인 하드 디스크를 예로 들어서 설명할 것이다.

• 디스크는 원판, 팔, 그리고 헤드로 구성된다. 원판에는 원 모양의 트랙이 존재하며 모든 원판에서 같은 위치를 갖는 트랙들의 집합을 실린더라고 한다.

• 트랙은 다시 몇 개의 섹터로 구분된다. 섹터는 디스크에서 데이터를 읽거나 기록할 때 기본 단위가 되며, 일반적으로 섹터의 크기는 512BYTE 이다. 한편 헤드는 각 원판의 읽기/쓰기가 가능한 면마다 하나씩 존재하게 된다. 따라서 헤드가 몇 개, 트랙이 (또는 실린더가) 몇 개, 그리고 각 트랙마다 섹터가 몇 개 등이 결정되면 디스크의 전체 용량 등 해당 디스크의 물리적 특성을 결정할 수 있게 된다.

• 디스크에서 데이터를 접근하는데 걸리는 시간은 탐색 시간 (SEEK TIME), 회전 지연 (ROTATIONAL LATENCY), 그리고 데이터 전송 시간 (TRANSMISSION TIME) 이라는 세가지로 구성된다. 탐색 시간이란 헤더를 요청한 데이터가 존재하는 트랙 위치까지 이동하는데 걸리는 시간이다. 회전 시간은 요청한 섹터가 헤드 아래로 위치될 떄까지 디스크 원판을 회전시키는데 걸리는 시간이다. 마지막으로 데이터 전송 시간은 헤드가 섹터의 내용을 읽거나 또는 기록하는데 걸리는 시간이다.

• 하지만 파일 시스템은 디스크를 물리적인 구조로 보지 않고 디스크를 논리적인 디스크 블록들의 집합으로 본다. 파일 시스템의 입장에서 본 디스크의 논리적인 구조를 표현한 것이다.

• 디스크 볼록은 0, 1, 2 등의 논리적인 번호를 하나씩 갖는다. 그리고 디스크 블록의 크기는 일반적으로 페이지 프레임의 크기와 같다. 일반적인 시스템에서는 페이지 프레임의 크기가 4KB 이며, 따라서 디스크 블록의 크기도 4KB가 된다. 파일 시스템 최대 병목 요소는 디스크 I/O 이다. 따라서 최근에 개발된 파일시스템의 경우 디스크 블록의 크기를 더 크게 설정하는 경향이 있다.

• 디스크 블록의 크기가 클 수록 한번의 DISK I/O로 더 많은 데이터를 메모리로 읽어들일 수 있기 때문이다. 그러나 디스크 블록의 크기와 ‘속도’ 측면에서의 성능은 비례하지만, ‘공간 효율성’ 면에서의 성능은 반비례한다. 평균적으로 데이터 블록 중 마지막 블록의 절반은 낭비된다. 따라서 어떤 디스크 블록 크기를 사용할 것인가는 용도에 맞게 사용자가 결정하는 것이 바람직하다.

• 만일 디스크 블록의 크기가 4KB 이고 섹터 크기가 512BYTE 라면 결국 하나의 디스크 블록에 8개의 섹터가 대응되게 된다. 따라서 파일 시스템이 하나의 디스크 블록을 읽어달라고 요청하면 결국 8개의 섹터 내용이 읽혀지게 된다. 디스크 블록의 번호를 이에 대응되는 섹터들로 맵핑 시키는 일은 디스크 디바이스 드라이버 또는 디스크 컨트롤러가 담당한다.

• 이제부터 디스크 블록의 할당과 회수 방법에 대해서 알아보도록 하자. 예를들어서 설명하였을 때 우선 디스크가 논리적으로 위의 그림과 같이 생겼으며 각 디스크 블록의 크기가 4KB 라고 가정하자.

• 이와 같은 환경에서 파일 시스템이 14KB의 크기의 파일 생성 요청을 받았다고 가정을해보자. 파일 시스템은 자신이 관리하고 있는 공간 (PARTITION) 내의 FREE 상태의 블록을 관리하고 있다가 여기에서, 이 파일을 위한 공간을 할당한다. 이 예에서는 파일 크기가 14KB 이므로, 4개의 디스크 블록이 필요하다. (각 디스크 블록의 크기가 4KB). 그림에서는 여유 있는 상태의 블록이 1, 5, 6, 9, 10, 13, 14, 15, 16 등이 있다.

디스크 블록 할당 방식 (연속 할당, 불연속 할당)

• 디스크 블록을 할당하는 방법에는 크게 연속 (SEQUENTIAL) 할당과 불연속 (NON-SEQUENCIAL) 할당 두 가지 방법이 있다. 연속 할당이란 파일에게 연속된 디스크 블록을 할당하는 방법이다. 위의 예에서 연속 할당 방법을 사용한다면, 13, 14, 15, 16 블록을 할당할 수 있고, 반면에 불연속 할당인 경우에는 1, 5, 6, 9 번과 같은 디스크 블록을 할당할 수 있다.

• 위의 두 가지 방법 중에서 어떤 방법이 파일 시스템에서 사용할 때 더 적당할까? 연속 할당은 불연속 할당에 비해서 파일을 읽는 속도가 빠르다. 왜냐하면 디스크의 탐색 시간을 줄일 수 있기 때문이다. 하지만 연속 할당의 경우 파일의 크기가 변하면 문제가 될 수 있다. 예를 들어서 생성한 14KB의 파일에 사용자가 새로운 내용을 추가하여 그 크기가 17KB로 커졌다고 가정해보자.

• 이제 이 파일은 5개의 디스크 블록을 필요로 하며, 따라서 파일 시스템은 이 파일에게 새로운 디스크 블록을 하나 더 할당해주어야 한다. 만일 연속 할당 기법을 사용하여 13, 14, 15, 16 디스크 블록을 청므 이 파일이 생성될 때 할당해 주었다면 더 이상 연속적으로 할당을 해줄 수 없고 결국 연속 할당을 위해서는 기존에 있던 디스크 블록들을 더 넓은 곳으로 복사한 후에 새로운 내용을 추가해야한다.

• 파일의 크기가 변하는 일은 매우 빈번하게 발생하는 일이다. 그리고 파일 크기가 커질 때 기존에 있던 파일 시스템을 설계할 때 연속 할당 방법만을 사용하는 경우는 거의 없다. (이 책을 작성한 필자의 경험으로는 멀티 미디어 데이터만을 고려한 파일 시스템에서 연속 할당을 하는 경우만 보았스템에서 연속 할당을 하는 경우만 보았다.)

• 불연속 할당 방법은 같은 파일에 속한 디스크 블록들을 연속적으로 저장하지 않는다. 따라서 위 14KB의 파일을 생성할 때 1, 5, 6, 9와 같은 디스크 블록을 할당할 수 있다. 그리고 이 파일의 크기가 켜져서 새로운 디스크 블록이 요구된다면 FREE 상태인 어떤 블록이라도 할당할 수 있다.

• 하지만 불연속 할당 방법에서는 파일에 속한 디스크 블록들이 어디에 위치하는지에 대한 정보를 기록해두여야 한다. 이를 위한 방법으로는 블록체인 기법, 인덱스 블록 기법, `FAT (File Allocation Table) 기법 등이 있다.

블록 체인 기법

• 블록 체인 기법은 파일에 속한 디스크 블록들을 체인으로 (즉 각 블록에 포인터를 두어서 다음 블록의 위치를 기록, 링크드 리스트와 유사) 연결해 놓는 방법이다. 따라서 특정 파일에 속한 첫 번째 디스크 블록에 가면 포인터를 이용하여 다름 블록위 위치를 찾아 갈 수 있다. 그러나 이 경우 lseek()와 같은 시스템 콜을 사용하여 파일의 끝 부분을 읽으려는 경우 어쩔 수 없이 앞 부분의 데이터 블록을 읽어야 하며, 또한 중간 블록이 유실될 경우에는 그 이후의 나머지 데이터까지 모두 잃게 된다는 단점이 존재한다.

인덱스 블록 기법

• 인덱스 블록 기법은 블록들에 대한 위치 정보들을 기록한 인덱스 블록을 따로 사용하는 방법이다. 이 방법에서는 lseek()를 사용하여 파일의 끝 부분을 접근하는 경우 데이터 블록을 일일히 읽어야 한다는 단점은 없지만, 만약 인덱스 블록이 유실되면 파일의 데이터 전체가 소실되는 문제가 있고, 또한 인덱스 블록을 위한 별도의 공간이 필요하며, 파일이 커져 인덱스 블록이 가득찰 경우 이를 해결할 방법이 필요하다.

FAT 기법

• FAT 기법은 같은 파일에 속해 있는 블록들의 위치를 FAT 라는 자료구조에 기록해 놓는 방법이다. 이 기법은 파일 시스템이 관리하는 공간 내에 전역적으로 존재하는 FAT 구조를 사용하여 파일에 속해있는 데이터를 찾아가는 방법이다. 즉 인덱스 블록 기법은 파일마다 인덱스 블록이 필요한데 FAT 기법에서는 파일 시스템 전체적으로 하나의 FAT가 존재하는 것이다.

• FAT 구조에서 FF는 파일의 끝을 의미하며 0은 FREE 상태를 나타낸다. 따라서 위의 그림에서 파일이 가리키고 있는 FAT 구조의 1번 블록을 읽어보면 다음 데이터 블록인 5번을 가리키고 있고 5번을 가면 6번 6번은 9번 9번에 가면 파일의 끝을 나타내는 FF가 쓰여있다. 이 기법 역시 파일의 중간 데이터를 읽기 위해 처음부터 읽을 필요는 없다.

• 한편 FAT 구조의 유실은 파일 시스템 내의 모든 파일이 소실된다는 문제가 있다. 따라서 요즘 대부분의 FAT 구조 파일 시스템은 FAT 내용을 중복해서 관리한다. 지금까지 설명한 바와 같이 각 기법은 서로 장단점을 가지며, 리눅스에서 주로 사용하는 파일 시스템인 EXT2, EXT3는 인덱스 블록 기법과 유사한 기법을 사용한다 그것이 바로 inode 이다.

FAT 파일 시스템

• 파일 시스템이 관리하는 데이터는 크게 메타 데이터와 유저 데이터로 구분할 수 있다. 메타 데이터는 FAT 테이블, 디렉터리 엔트리 그리고 수퍼 블록으로 구성된다. FAT 테이블은 이미 그림에서 설명하였다. 이제부터 디렉터리 엔트리의 구조를 살펴볼 것이다.

struct msdos_dir_entry {
    __u8 name[MSDOS_NAME] /* name and extension 11 */
    __u8 attr;            /* attribute bits */
    __u8 lcase;           /* case for base and extension */
    __u8 ctime_cs;        /* creation time, centiseconds (0 ~ 199) */
    __le16 ctime;         /* creation time */
    __le16 cdate;         /* creation date */
    __le16 adate;         /* Last access date */
    __le16 starthi;       /* High 16 bits of cluster in FAT32 */
    __le16 time, date, start /* time, date and first cluster */
    __le32 size;          /* file size (in bytes) */
};

• 대표적인 FAT 파일 시스템인 MS DOS 파일시스템에서 디렉터리 엔트리의 구조를 보여준다.

• 각 파일마다 디렉터리 엔트리를 하나씩 가진다. 이것은 마치 태스크가 하나 생성되면 task_struct 라는 구조체를 통해서 각 태스크를 관리하는 것과 유사하다. 디렉터리 엔트리가 모여서 디렉터리를 구성한다. 리눅스에서 디렉터리와 파일은 별도 구분없이 파일로 취급된다. 결국 디렉터리는 자신이 포함하는 파일의 이름들을 데이터로 가지고 있는 특수한 파일에 불과하다.

• 다른 파일 시스템의 디렉터리 엔트리는 어떨까? 개념은 비슷하다. 각각의 파일 시스템은 저마다 자신만의 디렉터리 구조체를 선언해 놓은 뒤, 파일이 생성될 떄, 이 구조체의 각 내용들을 읽어오도록 파일 시스템에 요청한다면 파일 시스템은 사용자가 요청한 파일의 이름을 가지고 디렉터리 엔트리를 찾아낸 뒤, 디렉터리 엔트리가 가지고 있는 정보를 통해서 데이터 블록을 찾아 사용자에게 제공해주는 것이다.

• 그렇다면 파일 시스템은 디렉터리 엔트리를 어떻게 찾을까? 디스크의 앞에서부터 순차 탐색을 하면 될 것인가? 불가능하지는 않겠지만 너무 느리기 때문에 이러한 방법을 실제 사용하지는 않는다. 리눅스 사용자 태스크의 현재 작업 디렉터리는 항상 task_struct 구조체에 유지하고 있기 때문에 상대 경로는 언제든 절대 경로로 변환이 가능하다.

• 파일 시스템은 루트 디렉터리의 디렉터리 엔트리를 읽고 여기서 데이터 블록을 찾아가서 원하는 파일을 읽게 된다. 그렇다면 최상위 루트의 디렉터리 엔트리 번호를 어떻게 알아낼지가 중요한데 이를 위해서 파일 시스템은 최상위 디렉터리가 위치하고 있는 곳 같은 정보를 적어서 자신이 관리하는 공간의 맨 앞 부분에 적어둔다.

• 이렇게 하면 나중에 언제라도 이 디스크를 사용하려 하는 시점에 디스크의 맨 앞 부분만 읽으면 ‘/’ 디렉터리의 위치를 알 수 있고, 따라서 ‘/’ 디렉터리 하위에 존재하는 모든 파일을 찾을 수 있게 된다. 이를 슈퍼 블록이라고 부른다.

• 슈퍼 블록 구조 역시 파일 시스템 각각의 구현에 따라서 모두 다른 모습이지만, 주요 기능과 유지해야할 정보는 개념적으로 동일하다. 파일 시스템의 전체적인 정보와 ‘/‘의 위치를 기억하는 것이다.

INODE의 구조

• 이 절에서는 리눅스의 디폴트 파일 시스템인 ext4 등 ext 계열 파일 시스템이 채택하고 있는 inode 구조에 대해서 살펴볼 것이다.

• 위의 그림은 fs/ext2/ext2.h에 정의되어있는 ext2_inode를 개념적으로 보여준다.

• i_blocks 필드는 이 파일이 몇 개의 데이터 블록을 가지고 있는지 나타내며, i_mode는 이 inode가 관리하는 파일의 속성 및 접근 제어 정보를 유지한다.

• i_links_count는 이 inode 를 가리키고 있는 파일 수를 (또는 링크 수를) 의미하며, i_uid와 i_gid는 파일을 생성한 소유자의 유저 아이디와 그룹 아이디를 의미한다.

• 그리고 i_atime, i_ctime, i_mtime은 각각 이 파일의 접근 시간, 생성시간, 수정 시간을 의미힌다. 이 변수들 중에서 i_mode에 대해서 좀 더 자세히 알아보자. i_mode는 16 비트로 구성되며 이 중에서 상위 4개의 비트는 파일의 유형을 의미한다.

• 파일의 유형으로는 정규 파일 (S_IFREG), 디렉터리 (S_IFDIR), 문자 장치 파일 (S_IFCHR), 블록 장치 파일 (S_IFBLK), 링크 파일 (S_IFLNK), 파이프 (S_IFFIFO), 그리고 소켓 (S_IFSOCK) 등이 있다.

• 그 다음으로 위치한 3개의 비트는 특별한 목적으로 사용된다. u 비트는 setuid(set user id) 비트로, 파일이 수행될 때 수행시킨 태스크의 소유자 권한이 아닌, 파일을 생성한 사용자의 권한으로 동작할 수 있도록 한다.

• 유사하게 사용되는 g 비트는 set-gid(set group id) 비트이다. 그리고 s 비트는 sticky 비트로 태스크가 메모리에서 쫒겨날 때, swap 공간에 유지되도록 할 때, 또는 디렉터리에 대한 접근 제어에 사용된다.

• 그 다음의 9개의 비트는 파일의 접근 제어 (읽기 / 쓰기 / 수행에) 사용된다. 처음 3개는 사용자에 대한 접근 제어에 사용되며, 그 다음 3개는 그룹에 대해서 그리고 마지막 3개는 다른 사용자들에 대한 접근 제어에 사용된다.

• inode 하단 부에는 i_block[15] 필드가 존재하는데, 이것은 파일에 속한 디스크 블록들의 위치를 관리하기 위해 사용된다. i_block[15]은 총 15개의 엔트리가 존재하는데, 이 중 12개는 직접 블록이고 3개는 간접 블록이다. 직접 블록은 실제 파일의 내용을 담고 있는 디스크의 데이터 블록을 가리키는 포인터이다.

• 반면 간접 블록은 인덱스 블록 (디스크 블록을 가리키는 포인터들을 갖는 블록)을 가리키는 포인터이다. 3개의 간접 블록은 다시 단일 간접 블록, 이중 간접 블록, 그리고 삼중 간접 블록으로 구분된다. 단일 간접 블록은 하나의 인덱스 블록을 가지며, 이중 간접 블록은 인덱스 블록을 2단계로, 삼중 간접 블록은 3단계의 인덱스 블록을 가진다.

• 이러한 EXT 계얼 파일 시스템의 inode 구조에서 지원할 수 있는 파일 최대 크기는 얼마일까? 디스크 블록의 크기가 4KB 라고 가정하면, 직접 블록으로 지원할 수 있는 파일의 크기는 48KB 이다. 단일 간접 블록은 하나의 인덱스 블록을 갖는다.

• 인덱스 블록도 결국 디스크 블록에 존재하며 따라서 인덱스 블록의 크기는 4KB이다. 인덱스 블록은 디스크 블록을 가리키는 포인터들로 구성되므로, 각 포인터를 위해 4BYTE가 필요하다고 볼 수 있다. 그럼 하나의 인덱스 블록에는 1024 의 포인터가 존재한다. 따라서 단일 간접 블록으로 지원할 수 있는 파일의 크기는 4MB이다. 같은 방식으로 계산한다면 이중 간접 블록은 4GB, 삼중 간접블록을 이용하면 4TB이다.

• 결국 디스크 블록의 크기가 4KB 이고 인덱스의 각 포인터(엔트리) 크기가 4BYTE 인 시스템 환경에서 아이노드가 지원할 수 있는 파일의 최대 크기는 48KB + 4MB + 4GB + 4TB가 된다.

• 하나의 파일이 사용하기에는 충분히 큰 공간이며, 이를 통해서 우리는 inode가 매우 깔끔하게 잘 설계되어 있음을 알 수 있다. 또한 거꾸로 생각해보면 파일의 크기가 48K 미만인 경우 별도의 인덱스 블록을 디스크에서 읽어올 필요가 없어서 EXT 계열의 파일 시스템은 최적의 성능을 보인다.

• 하지만 실제 리눅스가 지원하는 파일의 크기는 4GB 정도 밖에 되지 않고, 이는 비록 inode가 4TB 정도의 파일을 지원할 수 있지만, 커널 내부의 파일과 관련된 함수들이 사용하는 변수나 인자들이 32비트로 구현되어있기 때문이다.

• 예를 들면 파일 자료구조에는 파일 오프셋 (f_pos) 라는 변수가 있는데, 현재 이 변수는 32비트 크기를 갖는다. 결국 파일의 쓰거나 읽을 수 있는 위치가 가질 수 있는 값은 최대 4GB 인 것이다. EXT4는 이러한 제한을 해결하여 더 큰 크기의 파일을 지원한다.

• 지금까지의 논의에서 우리는 inode를 접근하면 파일의 속성 정보들과 파일에 속한 디스크 블록들의 위치를 파악할 수 있음을 알았다. 그럼 파일의 이름과 inode는 어떻게 연결될까? 이때 이용되는 것이 디렉터리 엔트리이다.

#define EXT2_NAME_LEN 255

struct ex2_dir_entry {
    __le32 inode;
    __le16 rec_len;
    __le16 name_len;
    char name[];
}

• 이 자료구조에는 우선 이 파일의 이름을 담는 name 필드가 존재한다. 다음으로 중요한 필드는 이 파일의 inode 번호이다. EXT2 파일 시스템은 모든 파일에게 고유한 inode 번호를 부여한다. ext3도 동일하다.

• 이 번호는 파일 시스템이 관리하는 공간의 앞 부분에 위치하고 있는 inode 테이블에서는 번호를 의미한다. inode를 이용하는 EXT2와 FAT를 이용하는 msdos 파일 시스템에서느 디렉터리 구조의 차이를 알 수 있다.

• EXT2 파일 시스템의 디렉터리 엔트리는 이름과 inode 번호 같은 간단한 정보만을 유지하며, 실제 데이터 블록 인덱싱과 같은 세부적인 정보는 inode 번호를 가지고 찾을 수 있는 inode 자료구조에 유지되는 것이다.

EXT2 파일 시스템

• 그럼 이제부터 EXT2 파일 시스템의 세부적인 구조에 대해 알아보면서 동작 원리를 이해해보도록 하자. EXT2 파일 시스템을 기반으로, 다양한 형태의 결함에 강인한 저널링 기능을 추가한 것이 EXT3, EXT4 파일 시스템이다. 따라서 EXT3와 EXT4 는 디스크에 실제 저장하는 대부분의 내용이 EXT2와 호환된다.

• 파일 시스템은 디스크를 관리한다. 디스크는 시스템에 장착되면 8장에서 살펴볼 장치 파일로 접근할 수 있다.

• 디스크가 시스템에 장착되면 디스크는 사용자가 원하는 개수만큼의 논리적인 영역으로 분할될 수 있다. 첫 번째 디스크가 3개의 파티션으로 분할된 예를 보여주고 있다. 현재 리눅스에서는 각 디스크마다 최대 64개가지 파티션을 분할 할 수 있다.

• 각 파티션에도 장치 파일 이름이 붙는데 첫 번째 디스크의 첫 번째 파티션은 hda1 두 번째 파티션은 hda2 세번째 파티션은 hda3 등의 이름이 붙는다. 그리고 두 번째 디스크의 첫 번째 파티션은 hda1 두 번째 파티션은 hdb2 등으로 이름이 붙는다.

• 파일 시스템은 파티션 당 하나씩 만들어진다. 우리는 mke2fs mkfs.XXX와 같은 명령어를 이용하여 파티션에 파일 시스템을 만들 수 있다.

• EXT2 파일 시스템을 만들면, 그 파티션은 복수개의 블록 그룹으로 나뉜다. 디스크의 성능을 높히기 위해서 서로 관련된 inode와 디스크 블록들을 인접한 실린더에 유지하여 디스크의 탐색 시간을 줄이려 하는 것이다.

• 사실 이러한 아이디어는 FFS(Fast File System)을 설계할 때 이미 사용된 것이다. 이를 위해서 Ext2는 인접한 실린더를 블록 그룹으로 정의하였다.

• 따라서 Ext2 파일 시스템을 구축하면 부트 스트랩 코드가 존재하는 부트 블록과 여러개의 블록 그룹으로 구성된다. 블록 그룹은 다시 수퍼블록, 블록 그룹 디스크립터, 디스크 블록을 위한 bitmap, inode를 위한 bitmap, inode table 그리고 data blocks 영역등 6가지 부분으로 구분된다.

참고 문헌

• 리눅스 커널 내부구조