목차
유닉스 운영체제의 기본 파일 시스템과 리눅스 파일 시스템 사례에 대해 알아보자.
유닉스 파일 시스템에서 파일의 종류에는 일반 파일, 디렉토리, 특수 파일이 있다.
파일 시스템은 부트 블록, 슈퍼블록, inode list, 데이터 블록들로 구성된다.
이때 inode list는 inode들의 1차원 배열이다.
inode란 유닉스 파일 시스템에서 FCB를 부르는 이름이며, 하나의 길이가 128바이트이다.
파일의 타입, 수정날짜, 파일 만든 사람, 파일의 내용에 해당되는 블럭의 주소, 링크 카운트 등 파일 속성(attribute) 정보가 들어간다.
링크 카운트란 몇개의 디렉토리에서 이 파일을 가리키느냐를 뜻한다.
파일을 구성하는 데이터 블록들의 주소를 어떤 식으로 유지하는 지에 대한 정보도 저장한다.
유닉스 파일시스템은 데이터 블록 관리에서 indexed allocation 방식을 사용하는데, index table을 약간 변형한다.
기존의 indexed allocation 방식은 인덱스 전체를 인덱스 블록이라는 별도의 블록에 모두 집어넣고, 인덱스 블록의 위치를 저장하는 파일 allocation 테이블을 만드는데,
실제 구현에서는 인덱스 블록이 몇번 블록인지에 대한 정보를 파일 allocation 테이블이 아니라 각 파일의 파일 컨트롤 블록에 둔다.
또, 유닉스 파일 시스템에서는 인덱스 넘버를 모두 인덱스 블록에 저장하는 것이 아니라, 첫 10개의 번호는 inode에 저장한다.
나중에는 12개로 확장되었다.
번호 하나에 4바이트씩 필요하니까 모두 40바이트만큼은 inode가 직접 인덱스 번호를 저장한다. 이 영역을 direct block field라고 한다.
이보다 더 많아질 경우 인덱스 블록을 사용하는 것이다.
인덱스 블록 하나에 번호를 저장하는 것을 single indirect block 필드라고 한다.
총 124개의 파일 내용을 가리키는데. 파일이 이보다 더 크다면 double indirect block 필드라는 inode의 또 하나의 필드를 통해 번호를 저장하는데, 이 번호는 인덱스 블록을 가리키고, 이 인덱스 블록 안에는 1024개의 인덱스가 저장되어있고, 이 인덱스는 각각 인덱스블록이 있다.
즉 싱글 indirect block 필드는 인덱스 블록을 한 번 거쳐서 파일 내용으로 가고, double은 두 번 거친다.
double indirect block 필드까지 사용한다고 하면 크기가 얼마나 될까?
먼저 direct block에서 블록 10개를 지정할 수 있는데, 내용 하나에 4KB이므로 디렉트 블록 필드로 직접 접근 가능한 파일의 크기는 40KB가 된다.
single indirect block 필드는 4KB 곱하기 인덱스 1024개 해서 4MB만큼의 파일 내용을 가리킨다.
double indirect block 필드는 4MB 곱하기 인덱스 1024개 해서 4GB만큼의 파일 내용을 가리킨다.
트리플 indirect block 필드는 4GB 곱하기 인덱스 1024개 해서 4TB만큼의 파일 내용을 가리킨다.
이보다 더 큰 파일을 만드는 것도 기술적으로 가능하다. 하지만 너무 많은 양의 데이터를 파일 하나에 모아서 저장하는 것 보다는 몇개에 나눠서 저장하는 것이 읽기나 쓰기 속도가 빠르기 때문에 효율적이지 않다.
예를 들면 double이나 트리플에서는 디스크 엑세스를 3, 4번 해야지만 파일 내용을 읽을 수 있기 때문에 시간이 많이 걸린다.
inode 자체는 파일 오픈이라는 과정을 통해 디스크에 저장되어있는 inode를 메인 메모리로 읽어 들여온다.
메인 메모리에서 내용을 읽게 되기 대문에 direct 블록이나 single indirect block의 번호들 자체는 메인 메모리에서 빠르게 읽을 수 있다. 하지만 디스크에 있는 인덱스 블록들의 내용은 디스크 자체에 접근해야하기 때문에 시간이 많이 걸린다.
즉 여러개의 작은 파일로 나눠서 저장하면 대게 10개의 direct 블록과 single indirect block 정도로 끝나면 index block을 최대 한번만 읽으면 되기 때문에 시간이 단축된다.
현대 유닉스 운영체제에서도 10개가 아닌 12개일 뿐 기본 방법은 그대로 사용한다.
리눅스 운영체제에서의 virtual file system에 대해 알아보자.
virtual file system이란 가상의 파일 시스템이다.
지금까지 살펴본 유닉스 시스템이나 윈도우스 ntfs 파일 시스템, 리눅스의 ext 파일 시스템은 실제 파일 시스템과 달리 논리적인 파일 시스템이다.
virtual file system을 만든 이유는, 파일 시스템마다 설계자가 다르기 때문에 그 구조나 파일 시스템에 접근하는 알고리즘이 서로 다른것이 일반적이다. 그러므로 파일에 접근하는 응용프로그램을 짤 때, 일반 사용자들이 파일을 열어서 데이터를 처리하고 저장하는 파일이 어떤 파일 시스템의 파일이냐에 따라 시스템 콜이 다르므로 파일 접근 방법이 달라진다.
그래서 리눅스는 파일 시스템 종류에 상관 없이 리눅스에서 다 접근해서 읽을 수 있게 만들었고, 그렇게 해주는 것이 논리적인 파일 시스템, virtual file system이다.
개념적 구조는 다음과 같다.
사용자 응용 프로그램은 실제 운영체제의 실제 파일 시스템이 아니라 virtual file system용 시스템 콜만 알면 된다.
이 시스템콜을 부르면 virtual file system에서 실제로 파일이 저장되어있는 path를 확인하고 읽으면 도스 파일 시스템 디스크 번호를 알 수 있고, 이를 통해 virtual file system이 시스템 콜을 도스 파일 시스템용 시스템 콜로 변환해준다.
이러한 방법으로 파일 시스템마다 별도의 프로그램을 짜지 않고 한가지 버전의 프로그램만 구현하면 되므로 편리하다.
virtual file system을 사용하지 않을때의 또다른 단점은, 운영체제가 모든 파일 시스템의 코드를 다 지니고 있으면 운영체제 소프트웨어 크기가 커져서 메인메모리를 많이 차지하는 문제이다.
그래서 리눅스는 필요한 파일 시스템만 그때그때 운영체제에 추가하고 필요 없으면 빼는 기능을 제공하는데 이를 모듈 기능이라고 한다.
