06. 파일 시스템의 이해

#파일 시스템
운영 체제가 저장매체의 파일을 쓰기 위한 자료구조 또는 알고리즘

 

 

#파일 시스템이 만들어진 이유?? - Block의 측면
0과 1의 데이터를 어떻게 저장매체에 저장할까??? 비트로 관리하기에는 오버헤드가 너무 크다.

→ 블록 단위로 관리하기로 함 (보통 4KB)
→ 블록마다 고유 번호를 부여해서, 관리하게 됨

→ 하지만 조금만 저장매체가 늘어나면 문제가 생김
→ 사용자가 각 블록 고유 번호를 관리하기 어려워짐

→ 추상적(논리적) 객체 필요 : 파일 등장 

사용자는 파일단위로 관리
각 파일에는 블록 단위로 내부적으로 관리

 

 

#파일 시스템이 만들어진 이유? - 저장방법의 측면
저장매체에 효율적으로 파일을 저장하는 방법이 필요했고
가능한 연속적인 공간에 파일을 저장하는 것이 좋으나
외부 단편화 문제, 파일 사이즈 변경 문제로 불연속 공간에 파일 저장 기능 지원의 필요성을 느끼게됨

블록 체인 기법 : 블록을 링크드 리스트로 연결, 문제는 끝에 있는 블록을 찾으려면, 맨 처음 블록부터 주소를 따라가야 한다는 단점이 있음 

인덱스 블록 기법 : 각 블록에 대한 위치 정보를 기록해서, 한 번에 끝 블록을 찾아갈 수 있도록 함

 

 

#다양한 파일 시스템
Windows : FAT, FAT32, NTFS 
블록 위치를 FAT라는 자료 구조에 기록

리눅스(UNIX) : ext2, ext3, ext4
일종의 인렉스 블록 기법인 inode 방식 사용

 

 

 

#파일 시스템과 시스템 콜
각 파일 시스템은 동일한 시스템 콜을 사용해서 다양한 파일 시스템 지원이 가능하도록 구현함
→ read/write 시스템 콜 호출 시, 각 기기 및 파일 시스템에 따라 실질적인 처리를 담당하는 함수 구현
→ 파일을 실제 어떻게 저장할지는 다를 수 있음

함수와 그 의미 (운영 체제 내부에서 파일 시스템에 관계없이 동일한 동작을 하도록 정함)
open → 이미 존재하는 파일을 읽기 또는 쓰기용으로 열거나, 새로운 파일을 생성하여 연다.
creat → 새로운 파일을 생성하여 연다.
close → open 또는 creat로 열려진 파일을 닫는다.
read → 열려진 파일로부터 데이터를 읽어 들인다. 
write → 열려진 파일에 데이터를 쓴다.
lseek → 파일 안에서 읽기/쓰기 포인터로 지정한 바이트 위치로 이동한다.
unlink/remove → 파일을 삭제한다.

 

 

 

#inode 방식 파일 시스템
세 가지 파일 시스템 기본 구조가 존재 
수퍼 블록 : 파일 시스템 정보
아이노드 블록 : 파일 상세 정보(PCB)
데이터 블록 : 실제 데이터(1~4KB)

 

#수퍼 블록(리눅스 기준 df)
파일 시스템 정보 및 파티션 정보를 포함하는 블록
파일 종류, 각각 1KB block이 몇 개에요 사용 중인 양은 몇 개이고 남은 양은 몇 개이고
어느 장소에 붙여져 있어요 등등 해당 파일 시스템에 대한 대표적인 정보를 갖고 있음

 

#inode와 파일 관계
파일 : inode 고유값과 자료구조에 의해 주요 정보관리
'파일이름 : inode' 로 파일이름은 inode 번호와 매칭
파일 시스템에서는 inode를 기반으로 파일 엑세스
inode 기반 메타 데이터(상세 정보) 저장

 

- 프로세스가 생성이 되면 프로세스 아이디가 할당되고 프로세스 ID 기반해서 PCB가 생성되고
그것을 기반으로 스케줄링 등 여러 작업을 하는 것

- 파일이 생성되면 inode 번호가 생기고 inode 블록이 생겨서 파일 처리를 한다.

 

 

 

#inode 기반 메타 데이터(파일 권한, 소유자 정보, 파일 사이즈, 생성 시간 등 시간 관련 정보, 데이터 저장 위치 등)
Mode, Owner info, Size, Timestamps ...
이런 것들이 inode 블록에 저장되어 있다.

 

inode 방식 파일 시스템 구조도

 

#cat files.txt

해당 파일의 inode 번호를 찾고 inode 번호에 맞는 inode 블록에 접근을 한다.
그런데 파일을 출력해달라고 하면 Direct blocks으로 간다. Direct blocks는 12개 주소공간을 가지는데 
각각 실제 데이터 블록의 주소를 가리키게 되어있다.

 

 

 

#is -al files.txt

inode 정보를 가져오고 해당 inode 블록으로 가서 Mode, Owner info, Timestamps 정보를 가져옴

 

 

#Direct blocks는 1~4KB 공간을 가진 데이터 블록에 대한 주소 공간을 12개를 가지는데
12개면 최대 48KB 밖에 가질 수 없어, 그렇다고 Direct block의 공간을 늘릴 것이냐? 그것도 문제임
그래서 나온 것이 Indirect Blocks - Single Indirect, Double Indirect, Triple Indirect

 

 

 

#inode 구조와 파일 데이터 
Single Indirect - 1개다.
4KB의 특정 블록을 가리키는데 이 블록에는 데이터를 가지고 있는게 아니라
direct block pointers 각각의 주소가 4 byte로 표현이 된다고 한다면 4KB를 4 byte로 나눠서
1024개의 실제 데이터를 가지고 있는 데이터 블록의 주소를 갖게 됨.
즉 1024 x 4KB = 4MB의 정보를 갖고 있음

Double Indirect
Single Indirect pointer의 주소를 가진 4KB의 블록을 가리키고 있음
1024 x 1024 x 4KB = 4GB

Triple indirect pointers
Double Indirect pointer의 주소를 가진 4KB의 블록을 가리키고 있음
1024 x 1024 x 1024 x 4KB =

 

inode 구조와 파일 데이터 구조도

#디렉토리 엔트리

디렉토리를 표현하는 데에 쓰이는 자료구조이다.

파일 시스템에 따라서 이를 구성하는 항목도 달라진다.

리눅스 파일 탐색의 예
각 디렉토리 엔트리를 탐색
각 엔트리는 해당 디렉토리 파일/디렉토리 정보를 가지고 있음

 

전체 파일 이름이 /home/ubuntu/link.txt 라고 한다면

 

'/' dentry에서 'home'을 찾고, 'home'에서 'ubuntu'를 찾고, 'ubuntu'에서 link.txt 파일이름에 해당하는 inode를 얻음

 

#가상 파일 시스템(VFS - Virtual File System)
필요한 함수들만 잘 구현해놓았다는 가정하에

어떤 파일 시스템을 쓰던 간에 일반 사용자는 open, read, write 같은 시스템 콜을 사용하면 동일한 동작을 하게 한다.

전통적인 리눅스 시스템에서 사용
파일 시스템 1, 2 에 대해서 시스템 콜이 동일하다고 할 때, 다른 기기나 디바이스로 확장 시킨다. 
예를 들면 Network등 다양한 기기도 동일한 파일 시스템 인터페이스를 통해 관리가 가능하다는 것
read/write 시스템 콜을 사용했을 떄, 각 기기별로 read_spec/write_spec 코드가 운영 체제 내에 구현만 되어있다면
파일처럼 관리가 가능하다.
모든 것은 파일이라는 철학을 따름
모든 인터렉션은 파일을 읽고, 쓰는 것처럼 이루어져 있음

 

 

#특수 파일 
외부적인 시스템 콜 인터페이스는 동일함

- 블록 디바이스
HDD, CD/DVD와 같이 대용량 데이터가 송수신 될 때 블록 또는 섹터 등 정해진 단위로 데이터 전송, IO 송수신 속도가 높음

 

- 캐릭터 디바이스
키보드, 마오스 등은 블록단위로 처리할 필요가 없기 떄문에 byte 단위 데이터 전송, IO 송수신 속도가 낮음