파일 시스템

파일시스템

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

 

파일 시스템이 만들어진 이유

• 0과 1의 데이터를 비트 단위로 관리하기에는 오버헤드가 너무 크다.
  • 블록 단위로 관리하기로 함 (보통4KB)
  • 블록마다 고유 번호를 부여해서 관리한다.
• 사용자가 각 블록 고유 번호를 관리하기 어려움 (추상적, 논리적 객체가 필요) 
  • 파일 개념이 생김 
  • 사용자는 파일 단위로 관리, 각 파일에는 블록 단위로 관리
• 저장매체에 효율적으로 파일을 저장하는 방법
  • 가능한 연속적인 공간에 파일을 저장하는 것이 좋으나 외부 단편화 문제가 발생
  • 외부 단편화, 파일 사이즈 변경 문제로 불연속 공간에 파일 저장 기능 지원이 필요
  • 블록체인: 블록을 링크드 리스트로 연결 (끝에 있는 블록을 찾으려면 처음 블록부터 주소를 따라가야 한다.)
  • 인덱스 블록 기법: 각 블록에 대한 위치 정보를 기록해서, 한번에 끝 블록을 찾아갈 수 있도록 한다.

다양한 파일 시스템

Windows

FAT, FAT32, NTFS ...

블록 위치를 FAT이라는 자료 구조에 기록

 

리눅스 (UNIX)

ext2, ext3, ext4...

일종의 인덱스 블록 기법인 inode 방식 사용

 

파일 시스템과 시스템 콜

파일을 실제 어떻게 저장하는지(파일시스템)는 다를 수 있으나 동일한 시스템콜을 사용해서 다양한 파일 시스템을 지원 가능하도록 구현

 

가상 파일 시스템

Network등 다양한 기기도 동일한 파일 시스템 인터페이스를 통해 관리 가능하다.

read/write 시스템콜 사용, 각 기기별 read_spec/ write_spec 코드 구현

• 모든 디바이스를 파일 시스템과 같이 다룬다.
  • 모든 것은 파일이라는 철학을 따른다.
  • 모든 인터렉션을 파일을 읽고 쓰는 것처럼 이루어져 있다.
  • 마우스, 키보드와 같은 모든 디바이스 관련 기술도 파일과 같이 다루어진다.
  • 모든 자원에 대한 추상화 인터페이스로 파일 인터페이스를 활용한다.

특수파일

디바이스

• 블록디바이스
  • HDD, CD/DVD와 같이 블록 또는 섹터 등 정해진 단위로 데이터 전송, IO 송수신 속도가 높다.
• 캐릭터 디바이스
  • 키보드 마우스등 byte 단위 데이터 전송, IO 송수신 속도가 낮음

 

inode 방식 파일 시스템

파일 시스템 기본 구조

• 수퍼 블록: 파일 시스템 정보
• 아이노드 블록: 파일 상세 정보
• 데이터 블록: 실제 데이터

수퍼블록

파일 시스템 정보 및 파티션 정보 포함

 

inode와 파일

파일: indoe 고유값과 자료구조에 의해 주요 정보 관리

파일이름:inode로 파일이름은 inode번호와 매칭

파일 시스템에서는 inode를 기반으로 파일 액세스

inode 기반 메타 데이터 저장

 

inode 구조와 파일

inode 번호를 찾고 해당하는 블록을 찾는다.

해당 블록에서 요청한 정보를 가져온다.

• inode 기반 메타 데이터
  • 파일 권한, 소유자 정보, 파일 사이즈, 생성시간 등 시간 관련 정보, 데이터 저장 위치 등
• Direct Blocks
  • 12개의 주소공간을 가리킨다. -> 실제 데이터 주소공간에 접근하여 요청한 정보를 가져온다.
• Single indirect
  • direct block pointers -> 12개의 주소공간 -> 실제 데이터 주소공간 
• Double indirect
  • single indirect pointers -> ...
• Triple indirect
  • double indirect pointers -> ...

 

프로세스와 비교

프로세스 생성 -> process ID -> PCB -> 스케줄링 등 여러 작업

파일생성 -> inode 번호 -> inode블록 -> 파일처리

 

디렉토리 엔트리

리눅스의 파일 탐색 ex) /home/ubuntu/link.txt

각 디렉토리 엔트리를 탐색

각 엔트리에는 디렉토리 파일, 디렉토리 정보를 가지고 있다

'/'(dentry)에서 home을 찾고 ubuntu를 찾고 link.txt 파일에 해당하는 inode 번호를 얻는다.

 

리눅스 파일 구조 (참고)

• /media, /mnt: 추가 저장 매체
• /dev: 디바이스 관련
• /etc: 설정
• /home: 로그인 관련
• /bin, /sbin: 쉘명령어의 실행파일, PATH 설정을 할 수 있다.
• /var/log/: 로그파일

 

파일 처리 성능 개선 기법 - 메모리에 파일 매핑 (mmap)

저장매체에 파일에 접근하는 과정은 오랜 시간이 걸리므로 파일 데이터를 메모리에 매핑해 성능을 개선하는 기법

#include <sys/mman.h>
void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset

• [start+offset] ~ [start+offset_length] 만큼의 물리 메로리 공간을 mapping할 것을 요청
• 보통 start: NULL 또는 0 사용, offset: mapping 되기 원하는 물리 메모리 주소로 지정
• prot: 보호 모드 설정
• PROT_READ(읽기 가능) / PROT_WRITE(쓰기 가능) / PROT_EXEC(실행 가능) / PROT)NONE(지정된 주소로 공간 지정)
• flags: 메모리 주소 공간 설정
• MAP_SHARED(다른 프로세스와 공유 가능 / MAP_PRIVATE(프로세스 내에서만 사용 가능 / MAP_FIXED(지정된 주소로 공간 지정)
• fd: device file에 대한 file descriptor

 

mmap 동작 방식

• mmap 실행 시 가상 메모리 주소에 file 주소 매핑
• 해당 메모리 접근 시 (요구 페이징, lazy allocation)
  • 페이지 폴트 인터럽트 발생
  • OS에서 file data를 복사해서 물리 메모리 페이지에 넣어줌
• 메모리 read 시: 해당 물리 페이지 데이터를 읽으면 됨
• 메모리 write 시: 해당 물리 페이지 데이터 수정 후, 페이지 상태 flag 중 dirty bit을 1로 수정
• 파일 close시: 물리 페이지 데이터가 file에 업데이트 됨 (성능 개선)

 

파일, 메모리, 가상 메모리

• 장점
  • read() write() 시 반복적인 파일 접근을 방지하여 성능 개선
  • mapping 된 영역은 파일 처리를 위한 lseek()을 사용하지 않고 간단한 포인터 조작으로 탐색 가능

 

• 단점
  • mmap은 페이지 사이즈 단위로 매핑
  • 파일의 크기가 1byte임에도 불구하고 4KB의 메모리를 차지하게 된다 (내부 단편화)