1. 파일 시스템 디자인
파일 시스템이 이용자에게 어떻게 보여지는지 디자인하는데 중요한 요소들은 다음과 같다.
1) 파일 메타 데이터(File Attributes)
2) 파일의 Operations
대부분 파일의 operation : open, close, read, write 등은 대부분 시스템 콜로 이뤄진다.
3) Directory Structure
4) Logical 파일 시스템과 Physical storage device간 mapping하기 위한 알고리즘과 데이터 구조
2. Layered File System
파일 시스템은 위 3단계의 레이어로 나뉜다.
(Logical File System, File Organization Module, Basic File System)
Application program은 사용자 관련 레이어, I/O 컨트롤은 커널이 담당하는 핸들링/실제 디바이스 드라이버과 관련된 레이어이다.
1) Logical File System
파일 시스템의 메타 데이터 (파일의 메타 데이터가 아니라 파일 시스템의 메타데이터!!)를 관리한다.
디렉토리 구조를 관리한다.
FCB (File Control Block)을 관리한다.
protection가 security를 담당한다.
2) File Organization Module
Logical Block address를 physical block address로 mapping
빈 공간을 관리한다.
3) Basic File System
하드웨어와 관련된 영역
physical block을 읽고 쓰기 위한 디바이스 드라이버와의 interaction
3. 오늘날의 파일 시스템
UNIX는 UFS(유닉스 파일 시스템) 을 사용한다. 버클리 FFS(Fast 파일 시스템)도 사용된다.
리눅스는 40개 이상, 매우 많은 파일시스템들을 지원한다. 리눅스가 초창기부터 가지고 있던 리눅스 native 파일 시스템도 있는데, 이는 EXT2, EXT3, EXT4이다.
MS 윈도우는 FAT 파일 시스템, FAT32, exFAT, NTFS등이 있다.
4. 파일 시스템 레이아웃 : 디스크 레이아웃
리눅스를 기준으로 살펴보자.
디스크에서 파일 시스템은 블록들의 Sequence이다.
1) Boot Contorl block
첫째 블록은 boot control block(블록 하나) B0이다.
부스트랩 코드가 저장된다. 컴퓨터 시스템을 처음 부팅할 때 ROM에 있는 부트 코드가 동작하면서, b0 영역의 boostrap code를 메모리로 옮긴다.
이 코드가 실행되면서 하드 디스크의 커널 이미지가 메모리에 올라가게 된다.
즉 Boot Contorl block에는, OS를 부팅시키는 역할을 하는 부스트랩 코드가 저장되어 있다.
2) volume Contorl block (=super block)
두번째는 volume control block(블록 하나) B1이다.
전체 파티션(file system)에 대해 몇 개의 블록인지, 한 블록의 크기는 얼마인지, 비어있는 블록의 개수, 빈 FCB 블록의 개수, Free Block Pointer(빈 블록의 위치 정보), Free FCB pointer(빈 FCB의 위치 정보) 정보를 가지고 있다.
3) FCB
FCB는 파일 컨트롤 블록으로서, B2~BK+1에 저장되어 있다.
FCB는 Inode이며, 파일 메타 데이터를 저장하는 영역이다. 파일의 위치, 사이즈, ownership, permission 등이 저장되어 있다.
만약 block 하나가 4kb인데 inode 하나가 128byte라면, 한 block 안에 32개의 inode가 들어갈 수 있다.
만약 block 전체가 k라면, 총 32k개의 inode 가 저장될 수 있다. 즉 이 파일 시스템에서 최대 생성 파일의 개수가 32k개이다.
4) data block
실제 데이터가 저장되는 데이터 블록이다.
루트 디렉토리 밑에 d, d 밑에 x 디렉토리가 있다고 하자. x 라는 파일이 x0, x1, x2라는 3개의 블록으로 저장되어 있다고 생각해 보자.
이 경우 실제 디스크에는 흩어져서 x0, x1, x2이 저장되어 있을 수 있다.
예를 들어 x0은 block 34, x1은 block 11번, x2는 b27번에 저장되어 있는 것이다.
이에 대한 맵핑 정보가 해당 파일의 FCB에 들어 있다.
5) directory structure
따로 영역이 있는 것이 아니며, 데이터블록 영역 안에 섞여 있다.
유닉스 파일 시스템 UFS는 위와 같은 형태이다.
파일조직에 대한 정보를 가진다.
파일 이름과 Inode 번호에 대한 정보를 가지고 있다.
.은 현재 디렉토리 자기 자신, ..는 parent directory를 의미한다.
UFS의 Disk layout
유닉스의 레이아웃도 역시 동일한 구조이다!
5. 커널 데이터 구조
1) Per-proces open file table
-> 프로세스 당 가진 open file table
2) System-wide open file table
-> 전체 시스템에 대한 open file table
📌 유닉스의 open file table
3) mount table
하나의 시스템을 다른 시스템에 걸어주어서, 전체 시스템이 하나의 hierarchy로 보이게 되는 것이다.
어떤 시스템이 mount되면, 그 때마다 mount table에 엔트리가 생긴다.
mount table의 각 entry는 다음과 같은 정보를 가진다.
mounted 파일 시스템의 디바이스 넘버(해당 영역에 대한 number)
mount된 파일 시스템의 super block을 포함하는 버퍼에 대한 pointer
mounted system의 root inode에 대한 pointer
mount point directory의 inode에 대한 pointer
4) directory structure cache (dcache)
최근 접근된 디렉토리의 정보를 읽어서 메모리에 넣어두는 것이다.
이를 위해 최근 접근된 디렉토리의 정보를 저장하는 영역이다.
🌱 VFS (Virtual File System)
실제 physically 존재하지 않지만, 다양한 파일 시스템을 지원하기 위한 '가상의 시스템'이다.
서로 다른 사용자들이 서로 다른 파일 시스템으로 seemless하게 넘어갈 수 있게 한다.
local disk hdd에는 a 파일 시스템, local disk ssd에는 b 시스템, remote system은 c파일 시스템이라고 해보자. 각 파일 시스템이 다르면 서로 다른 시스템 콜들을 지원한다.
application에서는 hdd에 접근할려면 a 시스템 콜을, sdd에 접근할려면 b 시스템 콜을 사용해야 하므로, 불편하다.
따라서 그 사이에 VFS 인터페이스를 만들어서 여기에서 한 종류의 시스템 콜로 통일해서 깔아준 것이다. Applciation은 그 VFS의 Uniform 한 시스템 콜을 하게 되고, VFS는 그 시스템 콜을 실제 시스템콜로 변환해 준다.
➡ VFS : 파일 시스템의 Generaic operation과 그들의 실제 implementation을 분리해주고, mapping해준다.
각 파일 시스템의 메타데이터 역시 전부 다르다.
따라서 VFS에서는 'Virtual Inode' = vnode를 사용한다.
따라서 메타데이터 역시 vnode로 만들어서, application 입장에서는 vnode 구조로 접근할 수 있게 하고 VFS에서 변환 시켜준다.
➡ VFS : file system-specific operation으로 변환해준다.
VFS가 없었을 때에는 각 시스템에 따라 일일이 시스템 콜을 다르게 해야했다.
VFS가 있으면 각 시스템콜을 신경쓰지 않고 그저 read, write를 해주면 된다.
