[운영체제] 25. File System Implementations 1

• 파일 시스템의 임플리멘테이션(구현)

• 디스크에 파일의 데이터를 저장하는 세 가지 방법이 있다.
• 디스크에 파일을 저장할 때 동일한 크기의 섹터 단위로 나누어 저장한다. 각각의 저장 단위를 논리적 블록 이라 부른다. 임의의 파일을 동일한 크기의 블럭으로 나누어 저장하는 방법이 있는데, 이 방법이 세 가지가 있는 것이다.

• 연속 할당은 하나의 파일이 디스크에서 연속해서 저장되는 방법이다. 예를 들어 블록 2개로 구성된 파일은 그림의 0번,1번이 연속해서 인접한 블록 번호를 가지게 저장이 된다. 19~24번 블록도 마찬가지다.
• 디렉토리에는 시작 블록과 블록의 길이가 명시된다.

• 연속 할당 방법은 외부 조각이 생기는 단점이 있다. 또 파일의 크기가 바뀔 수 있는데, 파일이 크지가 커지는 가능성이 제약된다. 따라서 어떤 파일이 커질 것을 비교해 미리 공간을 확보할 수 있다. 그러나 미리 공간을 할당해 놓고 공간을 낭비하는 내부 조각 문제가 생길 수 있다. 따라서 파일이 일정하지 않아 중간 hole이 생기는 것이 단점이다.
• 장점은 i/o가 빠르다는 점이 것이다. 한 번의 seek 으로 많은 양의 데이터를 한꺼번에 받아올 수 있다. 프로세스의 스왑 에어리어 용도로 사용할 수도 있다. 또 어느 정도의 i/o 시간을 데드라인으로 하는 리얼타임 파일 용으로 사용할 수 있다. 또 연속 할당의 경우 직접 접근이 가능하다.

• 링크드 얼로케이션은 홀 문제를 해결할수 있다. 빈 위치에 파일의 데이터를 배치하는 것이다. 디렉토리에 파일의 시작 위치를 갖고 그 위치에 가서 다음 위치를 파악한다.

• 외부조각이 발생하지 않는 장점이 있지만, 직접 접근이 불가능한 것이 단점이다. 네 번째 블록을 보려면, 1~3번째 블록을 거쳐야 한다. 즉 순차 접근만 가능하다. 또 reliabilty, 즉 파일을 구성하는 하나의 섹터가 배드 섹터가 되면 포인터의 유실로 뒷 부분을 잃을 수 있다. 또 만약 포인터를 위한 공간이 4바이트 정도 소요가 된다고 하면, 그만큼의 공간을 낭비하게 되는 문제가 생길 수 있다.
• 따라서 링크드 얼로케이션을 변형해 효율적으로 사용한 것이 FAT 파일 시스템이다. 이는 포인터를 별도의 위치에 보관한다.

• 인덱스드 얼로케이션은 직접 접근을 위해 디렉토리에 파일의 위치 정보를 담는 인덱스 블록을 표시한다. 인덱스 블록은 파일의 내용이 아닌 파일의 위치 정보를 블록 하나에 열거한 것이다. 이 경우 인덱스 블록만 확인하여 특정 번째 블록에 바로 접근 가능하다.

• 따라서 외부조각 없이 직접 접근이 가능한 장점이 있다. 그러나 아무리 작은 파일이라 하더라도 인덱스를 위한 블록 때문에 블록이 최소한 두개가 무조건 필요 하므로 이만큼의 공간 낭비가 있으며, 큰 파일의 경우 인덱스 블록 하나만으로 위치정보가 모두 표시 불가능하므로, 한 인덱스 블록에 마지막에 또다른 인덱스 블록의 위치를 표시하는 링크드 스킴이나, 멀티레벨 인덱스를 사용할 수 있다.

• 유닉스 파일 시스템의 구조다.
• 하나의 논리적 디스크=파티션이 있다. 이곳에 유닉스 파일 시스템을 설치한 것이다.
• 유닉스 시스템은 저장되는 구조가 네 가지가 있다. 부트블록, 슈퍼블록, 아이노드 리스트, 데이터 블록이다.

• 부트 블록은 유닉스 시스템이 아니어도 어떤 파일 시스템이든 항상 제일 앞에 나온다. 부스트랩 로더라 하여 부팅을 하기 위해 필요한 정보가 항상 0번 블록에 저장되어 있다.
• 슈퍼 블록은 파일시스템에 관한 총체적 정보를 담는다. 어디가 빈 블록이고 어디가 사용중인 블록인지, 어디까지가 아이노드 리스트고 어디까지가 데이터 블록인지 등이다.

• 파일의 메타 데이터는 이론상으로 디렉토리에 구현되어 있지만, 실제로는 디렉토리가 메타데이터를 모두 갖고있지는 않다. 유닉스의 경우 디렉토리는 일부분만 가지고 있고, 대부분의 메타데이터를 별도의 위치에 보관하는데 이를 아이노드 리스트라 한다. 위와 같이 파일 하나당 아이노드가 하나씩 할당 된다. 아이노드는 파일의 메타 데이터를 가진 구조다.
• 유닉스 파일 시스템에서 파일의 메타데이터 전부를 갖지는 않는다. 단 한가지, 파일의 이름만은 디렉토리에 저장되어 있다. 디렉토리에 파일의 이름과 아이노드 번호가 명시되어 있다. 이 공간이 데이터 블록이다. 데이터 블록은 파일의 실제 내용을 보관한다.
• 유닉스 파일 시스템은 인덱스 얼로케이션을 사용한다. 아이노드는 크기가 고정되어 있는데, 유닉스 구조를 보면 다이렉트 블록과, 싱글/더블/트리블 인다이렉트 블록 네가지로 파일의 위치정보를 구성한다. 파일의 크기가 작으면 다이렉트 블록만 가지고 파일의 위치정보를 표현하고, 대단히 큰 파일의 경우 인다이렉트를 사용하는데, 인덱스를 몇 번 따라가야 실제 파일의 위치를 찾을 수 있는지에 따라 싱글(한번), 더블(두번), 트리플(세번) 인다이렉트라 한다.
• 대부분의 파일은 크기가 매우 작으므로 다이렉트로 처리하고 아주 큰 파일은 인다이렉트로 처리하는 개념이다.

• FAT 파일 시스템의 구조다. FAT 파일 시스템은 링크드 얼로케이션의 단점을 해결한 시스템이다.
• 부트블록, FAT, 루트 디렉토리, 데이터 블록으로 구성된다.
• 파일의 메타 데이터를 FAT이라는 곳에 보관하는데, 이는 제한된 정보 즉 파일의 위치 정보만 FAT이 가지며 대부분의 메타 데이터를 디렉토리(데이터 블록)가 가진다.
• 링크드 얼로케이션은 배드 섹터가 생기면 뒤 정보가 유실되는 문제가 있었는데, FAT 파일 시스템에서는 특정 블록, 예를 들어 그림에서 217 블록의 다음 디렉토리 정보인 618을 디렉토리가 아닌 FAT에 담는 것이다. 따라서 FAT의 크기는 디렉토리의 블록 수와 일치한다. 그러므로 배드섹터가 생겨도 다음 위치 정보를 따라가는데 문제가 없다.
• FAT은 중요한 정보이므로 디스크에 2카피 이상을 보관한다.

• Free Space Management는 비어있는 블록을 관리하기 위한 것이다.
• 비어있는 블록을 관리하는 여러가지 방법이 있다.
• 먼저 비트맵 혹은 비트 벡터 방법이다. 이 방법은 각각의 블록 별로 번호들에 비트를 두어 몇 번째 블록이 사용 중인지를 0과 1로 표시한 것이다. 0은 빈 블록, 1은 파일에 할당된 블록이다. 파일의 크기가 커질 때는 비어있는 블록 중 하나를 할당하고, 파일이 삭제 되면 1번 블록 하나를 0으로 바꿔야 한다. 연속적인 n개의 빈 블록을 찾는데 효과적이다. 가능하면 연속적 공간에 할당하는 것이 디스크 헤드를 이동할 필요가 없어 좋기 때문이다.

• 다음은 링크드 리스트 방법이다. 비어있는 블록들을 연결하는 것이다. 공간의 낭비가 없지만 연속적인 빈 공간을 찾기 어렵다는 단점이 있다.
• 인덱스트 얼로케이션의 빈 블록을 관리하는 법이 그룹핑이다. 링크드리스트 방식의 변형인데 첫 번째 빈 블록이 n개 비어있는 블록의 위치를 포인터로 가리키고, 그 중 n-1번째까지의 블록은 그냥 빈 블록이고 마지막 n번째 블록은 또다시 n개의 빈 블록 인덱스를 가리키는 포인터를 갖는 방식이다. 그러나 역시 연속적 빈 블록을 찾기에는 효과적이지 않다.
• 연속적 빈 블록을 찾기에는 카운팅 방법이 효과적이다. 이는 빈 블록의 첫번째 위치에서부터 몇 개가 연속적으로 빈 블록인지의 정보를 유지한다. 프리 블록의 갯수를 담은 필드 정보를 확인해 연속적 빈 블록을 확인한다.

• 그림에서 회색이 빈 블록들인데 포인터로 빈 블록의 다음 빈 블록 위치를 가리키도록 한다.

• 디렉토리를 구현하는 방법이다. 디렉토리는 파일의 메타 데이터를 관리하는 파일이다.
• 디렉토리 파일의 내용을 저장하는 방법 중 하나는 리니어 리스트다. 단순히 파일과 파일의 메타데이터 정보를 순차적으로 저장하고 크기를 고정시켜 관리한다. 구현이 간단하지만, 특정 파일을 찾기 위해 쭉 확인해야 하므로 연산 시간이 오래 걸린다.
• 따라서 해시 테이블 방식을 사용하는데, 이는 해시 함수를 적용하여 파일의 해시 함수 결과 값에 해당하는 엔트리에 파일의 메타 데이터를 저장한다. 이 방식으로 파일을 찾는 시간을 줄인다. 그러나 서로 다른 파일의 이름에 대해 결과값이 같은 엔트리로 매핑되는, 충돌이 발생할 수 있다.

• 디렉토리에 파일의 메타데이터를 일부만 보관하고, 이전에 배웠듯이 아이노드나 FAT에 별도로 메타 데이터를 보관할 수 있다.
• 또 긴 파일 이름을 갖고 있는 경우, 일반적으로는 엔트리의 크기를 고정시켜 구현한다. 파일 이름이 길어지는 경우 엔트리의 크기가 고정되어 있으므로 이름의 앞부분을 저장하다가 엔트리를 벗어나게 되면 포인터를 두어 포인터가 가리키는 디렉토리 파일에 이름의 나머지를 저장하는 것이다.

• VFS는 버츄얼 파일 시스템의 준말로, 사용자가 파일 시스템에 접근할때 시스템 콜을 하는데, 파일 시스템 종류별로 서로 다른 시스템 콜을 사용하면 사용자가 혼란스러울 것이다. 그래서 어떤 파일시스템이 사용되든 상관없이 개별 파일 시스템의 윗 계층에 VFS라는 것을 두어 서로 다른 파일 시스템에 대해 동일한 시스템 콜 인터페이스를 통해 접근할 수 있도록 해주는 계층이다.
• NFS는 네트워크 파일 시스템으로, 파일 시스템이 로컬이 아닌 원격에 저장되어 이곳에 접근할 수도 있다.

• 그림의 클라이언트 컴퓨터가 있고, 서버 컴퓨터가 있다. 두 컴퓨터가 네트워크로 연결된 상황이다. 클라이언트가 VFS를 통해 파일 시스템에 접근하는데, 로컬에도 접근 가능하고, 원격에도 접근 가능한데 원격에 접근할 때 NFS를 사용한다.
• 먼저 VFS를 써서 특정 파일시스템에 접근하려는데 로컬에 그 파일 시스템이 없는 경우, NFS가 발동되어 서버에 있는 파일 시스템에 원격으로 접근해 가져오는 개념이다.

• 페이지 캐시는 이전에 설명했듯 페이징 시스템에서 사용하는 페이지 프레임을 캐싱의 관점에서 이야기하는 용어다.
• 버퍼 캐시는 파일의 데이터를 사용자가 요청했을 때 디스크에서 읽어 사용자에게 전달할 뿐 아니라 운영체제가 본인의 영역 중 일부에 저장하고 이후에 같은 요청이 오면 운영체제가 본인 영역 내에서 요청을 처리하는 것이다. 파일 시스템 관점이다.
• 페이지 캐시는 운영체제에게 주어지는 정보가 제한적이다. 하드웨어적 주소변환을 하므로 접근 시간 등을 알 수 없어 클락 알고리즘 등을 사용했지만, 버퍼 캐시는 파일을 접근할 때 시스템 콜을 하므로 운영체제에게 cpu가 넘어와 파일 접근 시간등이 운영체제에게 있으므로 LRU 알고리즘 등을 사용할 수 있다.
• 최근에는 페이지 캐시와 버퍼 캐시를 합쳐 관리하기도 하는데 이를 유니파이드 버퍼 캐시라 한다. 이는 버퍼 캐시도 페이지 단위로 관리한다는 의미이고, 운영체제에서 페이지 캐시와 버퍼 캐시를 같이 관리한다는 것이다.
• 파일 입출력하는 방법 중 버퍼 캐시를 이용하는 방법과 메모리 맵 i/o를 이용해 접근하는 방법이 있는데, 기존에는 파일을 오픈 후 read/write 시스템 콜을 하여 파일에 접근했지만, 메모리 맵 i/o는 파일의 일부를 버츄얼 메모리 영역에 매핑시켜 쓰는 것이다. 이러면 read/write 시스템 콜이 아닌 메모리에서 읽고 쓰는 것이다.

• 그림에 커널 영역과 사용자 영역이 있는데 커널 영역에 버퍼캐시가 있고, 사용자 메모리 영역에 페이지 캐시가 있다. 유니파이드 버퍼 캐시를 의미하는 것이다.
• 스왑 영역은 빠르게 데이터를 올리고 내려야 하므로 속도 효율성을 휘해 여러개의 페이지를 한꺼번에 올리고 내린다.