파일 시스템

728x90

디스크를 보조저장장치로 사용하는 이유

추가 장소를 사용하지 않고 재기록 가능
직접 접근할 수 있기 때문에 파일을 순차적 또는 무작위 방법으로 쉽게 접근할 수 있음

파일?

이름 있는 연관된 정보들의 컬렉션
OS는 다양한 저장 장치를 “file”이라는 동일한 논리적 단위로 볼 수 있게 함

파일 시스템?

데이터를 쉽게 store, located, retrieved할 수 있어서 저장장치를 더욱 효율적이고 편리하게 사용할 수 있게 한다
운영체제에서 파일을 관리하는 부분
파일, 파일 메타 데이터, 디렉토리 정보 등을 관리

디렉토리(directory)?

파일의 메타데이터 중 일부를 보관하고 있는 특별한 파일
디렉토리에 속한 파일 이름 및 파일의 메타데이터

Partition(=Logical Disk)?

하나의 물리적 디스크 안에 여러 파티션
물리적 디스크를 파티션으로 구성한 뒤 각 파티션에 file system을 깔거나 swapping 등 다른 용도로 사용할 수 있음
하드 디스크 하나 사서 C, D 드라이브로 파티션을 나누면 이를 논리적인 디스크라 함
- 운영체제가 보는 디스크는 논리적 디스크

계층적 파일 시스템

I/O control

장치 드라이버 루틴, 인터럽트 핸들러로 이뤄짐
메모리와 디스크 시스템 간의 정보 전송 담당

basic file system

저장 장치에서 블록을 읽고 쓰기 위해 적절한 장치 드라이버에 명령을 내림
메모리 버퍼와 캐시를 관리

file-organization module

파일과 파일의 논리적 block을 알고 있다
해당 모듈은 어느 디스크 공간이 비어 있는지 판단하는 “가용 공간 관리자”도 포함하고 있어 요청 시 비어있는 블록을 제공한다

logical file system

metadata 정보를 관리
- metadata는 실제 파일의 내용을 제외한 파일 시스템 구조를 가짐
디렉토리 구조를 관리
- 파일 이름이 symbolic할 경우 처리하여 파일 구성 모듈에게 필요한 정보를 제공하기 위해
파일 구조는 FCB에 의해 유지됨
- UNIX에서는 inode로 구현

UNIX 파일 시스템의 구조

boot block

운영체제를 부트시키는 데 필요한 정보를 가짐
해당 블럭은 모든 파일 시스템의 첫 번째 블록
UNIX는 boot block, Windows에선 master file table이라 함

super block

볼륨의 블록 수, 크기, 가용 블록의 수와 포인터, 가용 FCB 수와 포인터 같은 볼륨 정보를 포함

inode list

파일 이름을 제외한 파일의 모든 메타 데이터를 저장

data block

파일의 실제 내용을 보관
파일 이름과 inode번호가 pair로 저장됨

파일 생성

프로세스는 logical file system 호출
파일 시스템은 새로운 FCB를 할당
해당 디렉터리를 메모리로 읽어, 새로운 파일 이름과 FCB로 디렉터리 갱신
파일 시스템에 다시 씀

open()

/a/b 파일을 open하겠다
- 파일이 이미 다른 프로세스에 의해 사용 중인지 확인하기 위해 system-wide open file table을 검색
root의 metadata는 이미 알고있기 때문에 커널 메모리 영역에 root의 metadata를 올림
- root의 metadata를 통해 root의 content가 어디있는지 찾을 수 있다
root의 content는 디렉토리 파일이기 때문에 그 내용은 디렉토리 안에 있는 파일들의 메타 데이터이다
a라는 파일의 메타 데이터를 찾고, 이것을 메모리에 올린다
- 파일이 발견되면 FCB가 system-wide open file table에 복사된다
- FCB 뿐만 아니라 파일을 오픈한 프로세스의 수도 저장
메모리에 올려져있는 a의 메타 데이터를 이용하여 a의 실제 content를 찾음
b의 메타 데이터를 찾고 이것을 메모리에 올림
- system-wide open file table의 항목에 대한 포인터와 몇 개의 다른 필드를 갖는 새로운 항목이 per-process file descriptor table 안에 만들어진다
- 필드는 파일 안의 현재 위치(read, write 연산이 시작되는 위치)를 가리키는 포인터를 가지고 있음
open 시스템 콜은 프로세스 별 파일 테이블 내의 항목에 대한 포인터를 찾아 돌려줌
- 이후 모든 파일 연산은 해당 포인터를 통해 실행됨

디렉토리 구현

디렉토리 공간 할당, 관리에 따라 파일 시스템의 성능, 효율에 큰 영향을 미침
따라서 디렉토리 파일의 내용은 어떻게 저장할까??

선형 리스트

<file name, file의 metadata>의 list 형태
구현 간단
디렉토리 내 파일 찾기 위해서는 linear search 필요

해시 테이블

file name을 해시 함수를 통해 파일의 linear list의 위치로 바꿔준다
- linear list + hashing
선형 리스트보다 탐색 시간이 적음
다만 충돌 발생 가능

file의 metadata는 어디에 보관할까?

위 그림과 같이 디렉토리 내에 직접 보관
또는 디렉토리에는 포인터를 두고 다른 곳에 보관
- inode, FAT 등

file 이름 길이 문제

일반적으로 list에서 각 key 값 즉, entry 값은 일반적으로 “고정 크기”
만약 file name이 entry 길이보다 길어지면 entry 마지막 부분에 이름의 뒷 부분이 위치한 곳의 포인터를 둔다

할당 방법

한 저정장치에 여러 파일이 저장될텐데 각 파일을 저장장치에 어떻게 공간을 배치할까?
배치에 따라 효율성, 접근성이 달라지기 때문에 성능에 영향을 미치게 된다
할당 방법에는 연속 할당, 연결 할당, 색인(index) 할당이 있다

연속 할당

디렉토리에는 파일들의 메타 데이터를 내용으로 가지고 있다

파일이 저장장치 내에서 연속적인 공간을 차지함
디렉토리에는 파일의 첫 번째 블록의 주소와 길이로 정의됨

장점

구현 쉽다
순차 접근, 직접 접근 모두 지원
- 23번째에 접근하기 위해서는 19 + 4만큼해서 접근 가능

단점

최신 파일 시스템에서 사용 X
새로운 파일을 위한 가용 공간을 찾는 것이 어렵다
외부 단편화
파일 생성 시 얼마나 많은 공간을 할당할 것인가?
- 파일 생성자가 생성될 파일의 크기를 알 수 없기 때문에 우리는 공간을 미리 할당함
- 공간이 너무 작으면 파일이 커질 수 없다
- 공간이 너무 크면 내부 단편화가 발생

연결 할당

블록이 링크드리스트로 저장
디렉토리는 파일의 첫 번재, 마지막 블록 포인터를 가지고 있음
연속 할당의 모든 문제를 해결
순차적 접근에 적합

장점

외부 단편화 발생 X

단점

한 섹터가 고장나 포인터가 고장나면 많은 부분을 잃게 됨(reliability 문제)
직접 접근이 불가
- 10번째 블럭에 가기 위해선 1번째 블럭이 필요하고, 1번째 블럭에 접근하기 위해서는 16블럭을 접근해야함
block의 일부가 포인터를 위한 공간이 되어 공간 효율성 떨어짐
- sector : 512bytes
- pointer : 4bytes
- 즉, 508 byte의 데이터 저장

단점을 보완하기 위한 클러스터 사용

공간 효율성의 해결책 중 하나로 블록을 모아 “클러스터”를 만들고, 이를 할당한다
파일 시스템은 4개의 블록을 하나의 클러스터로 정의하고, 클러스터 단위로만 작동한다

클러스터 장점

포인터는 파일 공간의 훨씬 적은 비율 사용
논리적-물리적 블록 매핑 간단하게 유지, 디스크 헤드 탐색 줄어듦

클러스터 단점

내부 단편화가 증가
소량의 데이터 요청이 많은 양의 데이터 전송을 유발하기 때문에 I/O 성능 저하

FAT(File Allocation Table)

연결 할당의 변형
포인터를 별도의 위치에 보관하여 reliability와 공간 효율성 문제 해결
- data block의 포인터 하나가 유실되도 FAT에도 위치가 저장되어있기 때문에 해결
- FAT의 정보를 읽어 임의의 블록 위치를 알아낼 수 있기 때문에 random access 가능
파티션의 시작 부분이 FAT로 사용
파일의 메타 데이터 중 일부를 FAT에 저장
- 위치 정보
원래 파일의 메타 데이터는 디렉터리가 가지고 있지만 FAT에서는 파일 이름을 비롯한 사이즈 등 attribute가 디렉터리가 가지고 있고, 그 파일의 시작 위치가 어디인지는 FAT가 가지고 있음
FAT 블럭의 개수는 Data block의 block 개수와 같다

과정

처음 파일이 217에 있다
data block에서 217을 찾는다
다음 블럭을 알기 위해 FAT에서 217번째로 이동
다음은 618이니까 data block에서 618을 간다
위의 과정을 반복한다

색인(index) 할당

연결 할당은 FAT가 없으면 직접 접근 방식을 할 수 없다
index 할당은 모든 포인터들을 index block이라는 하나의 장소에 관리하여 직접 접근 문제를 해결

장점

외부 단편화 발생 X
직접 접근 가능
- 메모리 내에 index block이 존재할 경우

단점

작은 파일일 경우 공간 낭비
너무 큰 파일의 경우 하나의 block으로 저장하기에 부족
- linked scheme, multi-level index로 해결 가능

단점을 보완하기 위한 방법

linked scheme

파일 크기가 크면 여러 개의 index 블럭을 연결
index block의 마지막 항이 다음 index block의 주소의 포인터를 저장

multilevel index

linked scheme의 변형
여러 개의 두 번째 index block 집합을 가리키기 위해 첫 번째 level의 block을 사용

UNIX inode는 direct, single, double, triple block을 가지고 있다
이는 파일 크기에 따라 direct → triple 순으로 가게 된다

비어 있는 부분들은 어떻게 관리할까?

이를 free space management라 한다

비트 벡터

비어있는 곳은 1으로 나타낸다
bit map은 부가적인 공간이 필요
- bit map이 메인 메모리 내에 존재하지 않으면 비효율적
- 디스크의 크기가 증가하는 것을 고려하면 더 큰 bit map이 필요하게 됨
연속적인 n개의 free block 찾는데 효과적

연결 리스트

모든 free block을 링크로 연결
연속적인 가용공간을 찾는 것은 어렵
- 리스트를 순회하려면 매번 디스크에 접근해야 하므로 효율적 X
공간 낭비 X

grouping

연결 리스트의 변형으로 첫 번째 블록에 n개의 블록 주소를 저장
연결 리스트와 달리 다수 개의 가용 블록 주소들을 쉽게 찾을 수 있음

VFS & NFS

VFS(Virtual File System)

서로 다른 다양한 file system에 대해 동일한 시스템 콜 인터페이스를 통해 접근할 수 있게 해주는 OS의 layer

NFS(Network file System)

분산 시스템에서는 네트워크를 통해 파일이 공유될 수 있음
NFS는 분산 환경에서의 대표적인 파일 공유 방법

Page Cache & Buffer Cache

버퍼 캐시

파일 시스템을 통한 I/O 연산은 메모리의 특정 영역인 buffer cache 사용

페이지 캐시

paging system에서 사용하는 페이지를 cache 관점에서 설명하는 용어
단위는 페이지

memory mapped I/O

파일의 파일부를 가상 메모리에 mapping
mapping시킨 영역에 대한 메모리 접근 연산은 파일의 입출력을 수행하게 함

통합 버퍼 캐시(Unified Buffer Cache)

buffer cache가 page cache에 통합됨

파일을 오픈하고 접근하는 방식에는 memory mapped과 표준 시스템 콜을 사용할 수 있다

시스템 콜은 버퍼 캐시를 이용할텐데, 만약 통합 버퍼 캐시가 없다면 "메모리 매핑"은 페이지 캐시와 버퍼 캐시를 "모두" 요구한다

메모리 매핑은 파일 시스템으로부터 디스크를 읽기 -> 버퍼 캐시에 저장 -> 가상 메모리 시스템에서 버퍼 캐시에 있는 파일을 페이지 캐시에 복사

왜 버퍼 캐시에 있는 파일을 페이지 캐시에 복사해야할까?

가상 메모리 시스템은 버퍼 캐시와 인터페이스 할 수 없기 때문에 버퍼 캐시에 있는 파일이 페이지 캐시에 복사되어야한다

파일 시스템 데이터를 두 번 캐싱하기 때문에 이를 이중 캐싱이라하고, 메모리 낭비와 필요없는 데이터 이동으로 인해 CPU와 I/O 사이클을 낭비할 뿐만 아니라 비일관성 문제가 발생할 수 있다

그래서 통합 버퍼 캐시를 제공함으로써 메모리 매핑과 시스템 콜은 "같은" 페이지 캐시를 사용하게 된다

이는 통합 버퍼 캐시가 없을 경우의 단점을 극복하고, 가상 메모리 시스템이 파일 시스템 데이터를 관리할 수 있도록 한다

REFERENCES

- ABRAHAM SILBERSCHATZ ET AL., OPERATING SYSTEM CONCEPTS, NINTH EDITION, WILEY, 2013
- 반효경, 운영체제와 정보기술의 원리, 이화여자대학교 출판부, 2008