파일 시스템

Single Ko·2023년 5월 2일

operating system

목록 보기

12/13

File System

File and File System

✨ File

"A named collection of related information" (관련된 정보 자료들의 집합에 이름을 붙인 것)
레코드(Record) 혹은 블록(Block) 단위로 비휘발성 보조기억장치에 저장
운영체제는 다양한 저장 장치를 file이라는 동일한 논리적 단위로 볼 수 있게 해 줌
Operation (파일에 관련된 연산)
✓ create, read, write, reposition (lseek), delete, open, close 등

✨ File attribute (= 파일의 metadata)

파일 자체의 내용이 아니라 파일을 관리하기 위한 각종 정보들
✓ 파일 이름, 유형, 저장된 위치, 파일 사이즈
✓ 접근 권한 (읽기/쓰기/실행), 시간 (생성/변경/사용), 소유자 등
파일 자체의 내용은 아니다

✨ File system

운영체제에서 파일을 관리하는 부분
시스템 내의 모든 파일에 관한 정보를 제공하는 계층적 디렉터리 구조
파일 및 파일의 메타데이터, 디렉토리 정보 등을 관리
파일의 저장 방법 결정
파일 보호 등

Directory and Logical Disk

✨ Directory

파일의 메타데이터 중 일부를 보관하고 있는 일종의 특별한 파일
그 디렉토리에 속한 파일 이름 및 파일 attribute들
operation
✓ search for a file, create a file, delete a file
✓ list a directory, rename a file, traverse the file system

✨ Partition (=Logical Disk, 운영체제가 보는 디스크)

하나의 (물리적) 디스크 안에 여러 파티션을 두는게 일반적
여러 개의 물리적인 디스크를 하나의 파티션으로 구성하기도 함
(물리적) 디스크를 파티션으로 구성한 뒤 각각의 파티션에 file system을 깔거나 swapping 등 다른 용도로 사용할 수 있음

Open()

디스크에서 메인 메모리로 메타데이터를 올려놓는 작업

✨ open("/a/b/g")

디스크로부터 파일 c의 메타데이터를 메모리로 가지고 옴
이를 위하여 directory path를 search
✓ 루트 디렉토리 “/”를 open하고 그 안에서 파일 “a”의 위치 획득
✓ 파일 "a"를 open한 후 read하여 그 안에서 파일 "b"의 위치 획득
✓ 파일 "b"를 open한 후 read하여 그 안에서 파일 "c"의 위치 획득
✓ 파일 “c”를 open한다.
Directory path의 search에 너무 많은 시간 소요
✓ Open을 read/write와 별도로 두는 이유임
✓ 한번 open한 파일은 read/write directory search 불필요
Open file table
✓ 현재 open 된 파일들의 메타데이터 보관소 (in memory)
✓ 디스크의 메타데이터보다 몇 가지 정보가 추가
1. Open한 프로세스의 수
2. File offset: 파일 어느 위치 접근 중인지 표시 (별도 테이블 필요)
File descriptor (file handle, file control block)
✓ 프로세스 별 Open file table에 대한 위치 정보

File Protection

✨ 각 파일에 대해 누구에게 어떤 유형의 접근(read/write/execution)을 허락할 것인가?

✨ Access Control 방법

Grouping
✓ 전체 user owner, group, public의 세 그룹으로 구분
✓ 각 파일에 대해 세 그룹의 접근 권한(rwx)을 3비트씩으로 표시, 9비트로 표현 가능
(예) UNIX
```
owner group  other
 /\     /\     /\
rWX    r--    r--
```
Password
✓ 파일마다 password를 두는 방법 (디렉토리 파일에 두는 방법도 가능)
✓ 모든 접근 권한에 대해 하나의 password : all-or-nothing
✓ 접근 권한별 password: 암기 문제, 관리 문제

File System의 Mounting
서로 다른 파티션에 존재하는 파일 시스템에 접근할 수 있는 방법 - Mount

Access Methods

✨ 시스템이 제공하는 파일 정보의 접근 방식

순차 접근 (sequential access)
✓ 카세트 테이프를 사용하는 방식처럼 접근
✓ 읽거나 쓰면 offset은 자동적으로 증가
직접 접근 (direct access, random access)
✓ LP 레코드 판과 같이 접근하도록 함
✓ 파일을 구성하는 레코드를 임의의 순서로 접근할 수 있음

Allocation of File Data in Disk

✨ 파일 데이터를 디스크에 할당하는 방법으로 다음 세 방식이 존재한다.

Contiguous Allocation
Linked Allocation
Indexed Allocation

1. Contiguous Allocation

연속 할당(Contiguous Allocation)은 말 그대로 파일을 디스크에 연속되게 저장하는 방식이다.
디렉터리에는 파일이 시작 부분의 위치와 파일의 길이에 대한 정보를 저장하면 전체를 탐색할 수 있다.
장점
1. 빠른 I/O가 가능하다. Direct access(=random access)가능.
2. Realtime file 용으로, 또는 이미 run 중이던 process의 swapping 용(임시 저장)
단점
1. 외부 단편화가 발생한다
2. 파일의 크기를 키우기가 어렵다
3. 파일의 커질 가능성을 고려해서 미리 큰 공간을 할당한다면 내부 단편화가 발생할 수도 있다.

2. Linked Allocation

연결 할당(Linked Allocation)은, 연속적으로 할당하지 않고 빈 위치면 자유롭게 할당될 수 있다.
다음 읽어야 할 위치를 연결 리스트처럼 포인터로 가리킨다. 따라서 디렉터리에는 파일이 시작하는 위치와 끝나는 위치만 저장된다.
장점
1. 외부 단편화가 발생하지 않는다.
단점
1. Random access가 불가능(순차 접근만 가능)
2. 포인터를 위한 공간이 block의 일부가 되어 공간 효율성을 떨어뜨린다.
3. 만약 한 sector가 고장 나 포인터가 유실되면 많은 부분을 잃게 되는 신뢰성 문제
📌 단점을 보완하기 위해FAT(File-allocation table) 파일 시스템. 이는 포인터를 별도의 위치에 보관하여 신뢰성 문제와 공간 효율성 문제를 해결한다.

3. Indexed Allocation

색인 할당(Indexed Allocation)은 한 블록에 하나의 파일에 대한 데이터의 index들을 모두 저장하는 방식이다. 따라서 디렉터리에는 해당 블록의 위치만 담게 된다.
장점
1. External fragmentation(외부 단편화)이 발생하지 않음
2. Direct access 가능
단점
1. Small file의 경우 공간 낭비 (실제로 많은 file 들이 small)
2. Too Large file의 경우 하나의 block으로 index를 저장하기에 부족
  - 해결방법 : linked scheme , multi-level index

UNIX 파일시스템의 구조

✨ 유닉스 파일 시스템의 중요 개념

Boot block : 부팅에 필요한 정보 (bootstrap loader)
Superblock : 파일 시스템에 관한 총체적인 정보를 담고 있다.
Inode : 파일 이름을 제외한 파일의 모든 메타 데이터를 저장
Data block : 파일의 실제 내용을 보관

FAT File System

Boot block : 어느 시스템이나 항상 boot block은 부팅에 필요한 정보를 가지고있음.
FAT : 데이터의 위치를 가지고 있음. 파일이 n개라면 FAT은 n-1개가 존재
Data block : 파일의 메타 데이터와 정보들

Free space Management

✨ Bit map

0이면 비어 있는 값이고, 1이면 sector 저장된 공간이다.
0 또는 1을 저장할 부가적인 공간을 필요로 한다.
연속된 n개의 free 블록을 찾기 효과적

✨ Linked list

모든 free 블록을 링크로 연결 (free list)
연속적인 가용 공간을 찾기 어렵다.
공간의 낭비가 없다.

✨ Grouping

Linked list 방법의 변형
첫 번째 free 블록이 n 개의 포인터를 갖는다.
n-1 포인터는 free data block을 가리킴
마지막 포인터가 가리키는 block은 또 다시 n 포인터를 가짐

✨ Counting

프로그램들이 종종 여러 개의 연속적인 블록을 할당하고 반납한다는 성질에 착안하였다.
(first free block, # of contiguous free blocks)을 유지

Directory Implementation

✨ Linear list

<file name, file metadata> list
구현이 간단
디렉토리 내에 파일이 있는지 찾기 위해서는 linear search 필요 (time-consuming)

✨ Hash Table

linear list + hashing
Hash table은 file name을 이 파일의 linear list의 위치로 바꾸어줌
search time을 없앰
Collision 발생 가능

✨ File의 metadata 보관 위치

디렉토리 내에 직접 보관
디렉토리에는 포인터를 두고 다른 곳에 보관 (Inode, FAT 등...)

✨ Long file name의 지원

<file name, file metadata>의 list에서 각 entry는 일반적으로 고정 크기
file name이 고정 크기의 entry 길이보다 길어지는 경우 entry의 마지막 부분에 이름의 뒷부분이 위치한 곳의 포인터를 두는 방법
이름의 나머지 부분은 동일한 directory file의 일부에 존재

VFS and NFS

✨ Virtual File System (VFS)

서로 다른 다양한 파일 시스템에 대해 동일한 시스템 콜 인터페이스(API)를 통해 접근할 수 있게 해 주는 OS의 레이어

✨ Network File System (NFS)

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

VFS를 사용해 디스크에서 파일 접근, 네트워크를 통한 파일 시스템에도 NFS사용 중

Page Cache and Buffer Cache

✨ Page Cache

가상 메모리의 페이징 시스템에서 사용하는 페이지 프레임을 캐싱의 관점에서 설명하는 용어
Memory-Mapped I/O를 쓰는 경우 파일의 I/O에서도 페이지 캐시를 사용한다.

✨ Memory-Mapped I/O

파일의 일부를 가상 메모리에 매핑한다.
매핑한 영역에 대한 메모리 접근 연산은 파일의 입출력을 수행하게 한다.

✨ Buffer Cache

파일 시스템을 통한 I/O 연산은 메모리의 특정 영역인 버퍼 캐시를 사용한다.
File 사용의 locality 활용
한 번 읽어 온 블록에 대한 후속 요청 시, 버퍼 캐시에서 즉시 전달
모든 프로세스가 공용으로 사용
Replacement algorithm 필요 (LRU, LFU 등)

✨ Unified Buffer Cache

최근의 OS에서는 기존의 버퍼 캐시가 페이지 캐시에 통합됨.

Unified Buffer Cache를 사용할때와 하지 않을때의 차이

요즘에는 buffer cache라는 말은 Paage cache에 거의 흡수되어 사용되는 느낌.

프로그램의 실행

Code 부분 : 당장 사용되지 않는 것이 Swap형태로 내려가는 것이 아니고 지우면 된다. 필요하면 파일 시스템에 실행 파일로 저장되어 있는 코드를 데리고 오면 된다.
=> Memory mapped I/O

✨ Memory Mapped I/O vs read()

Memory Mapped I/O
✓ 가상 메모리에 올라 온 영역이 곧 파일이므로 시스템 콜 없이 I/O 작업을 할 수 있다.
✓ 페이지 캐시에 있는 내용을 복사할 필요가 없다.
✓ 여러 프로세스가 mmap() 을 사용하여 같은 영역을 공유하여 사용하면 일관성 문제가 발생할 수 있다.
read()
✓ 매번 운영 체제의 중재를 받는다.
✓ 페이지 캐시에 있는 내용을 복사해야 한다.
✓ 여러 프로세스가 read() 를 사용해도 일관성 문제가 발생하지 않는다.

Single Ko

공부 정리 블로그

이전 포스트

가상 메모리

다음 포스트