File System
파일이란?
Logical view of storage unit
✅ 정의
- 사용자의 관점 : 바이트들의 시퀀스
- 파일 시스템의 관점 : 디스크 블럭의 collection
✔️ 파일 시스템이 해야 하는 일 : 이름과 offset을 변경해서 디스크 블럭에 접근함 !
✅ Operation
- Create / Delete, Open / Close : 디스크 space 할당 및 파일 시스템 업데이트
✔️ fopen(), fclose() - Read and Write : 디렉토리 서치
✔️ fread(), fwrite()
등등
연산자는 모두 시스템 콜이다!
✅ File Information
✔️ File pointer : 프로세스가 파일을 읽거나, 쓸 때 시스템은 마지막으로 읽거나 쓴 위치에서부터 다시 검색을 시작
- 실제 파일은 하드디스크에 있음
어떻게 접근 ? ➡️ sequential , direct access
어떻게 할당 ? ➡️ disk allocation method
✔️ File-open count : 여러 프로세스가 한 파일을 여러번 읽을 수 있기 때문에 카운트를 트랙킹
✔️ File metadata : 파일 자체의 내용이 아니라 파일을 관리하기 위한 각종 정보를 일컫음
- File name, id, location size ,, etc.
✔️ File control block(FCB) : 파일 정보를 담고 있음
✔️ Directory : 파일의 메타데이터 중 일부를 보관하고 있는 일종의 특별한 파일
- 대부분 트리 형태 🎄
파일시스템이란 ?
운영체제에서 파일을 관리하는 부분
✔️ 파일 및 파일의 메타데이터, 디렉토리 정보 등을 관리함
✅ Fopen() 실행했을 때 실행되는 순서
1. open()을 시스템콜로 리퀘스트 함
2. 디스크에 있던 root의 meta data가 메모리로 올라감
3. root의 주소를 찾아가서 a의 메타데이터에 접근함
4. a의 메타데이터가 메모리에 올라감
5. a의 주소를 찾아가서 b의 메타데이터에 접근함
6. b의 메타데이터가 메모리에 올라감
7. 프로세스가 생성이 됨
8. 디스크 상의 버퍼 캐시(빨간색 상자)에 접근한다
9. 커널 메모리 상의 버퍼 캐시에 접근한다
10. 사용자 메모리 상의 버퍼 캐시에 접근한다.
File Access
어떻게 접근? 에 해당하는 부분
Sequential Access
파일을 처음부터 순서대로 access함
✔️ 가장 많이 쓰이는 방법임
✔️ File pointer가 current position부터 읽는 것
Direct Access
아무 위치나 내가 원하는 위치에서부터 access함
✔️ 프로그램이 정해진 순서에 따른 것 ❌, 랜덤하게 읽거나 쓸 수 있도록 함.
ex) 데이터베이스 시스템
✔️ Relative (logical) block number 을 사용해서 구현
- block한테 숫자를 연속적으로 부여
- 그리고 read(n)으로 n번째 블럭의 값을 읽어옴
File allocation
어떻게 할당? 에 해당하는 부분
🚀 목적 : 디스크 공간의 낭비 ❌ 빠르게 파일에 접근하고자 함
✅ Contiguous Allocation
하나의 파일이 디스크에 연속으로 저장되는 방법
나누어진 각 블럭들이 연속된 번호를 부여받아 저장이 됨
- 간단하게 시작하는 위치(block #) & 길이(number of blocks) 만 있으면 됨
✔️ 장점 :
- 빠르다 ( seek time 🔽 )
모두 연속해서 붙어 있으므로 추가적인 탐색 비용이 소요되지 ❌ - 원하는 위치를 찾기 쉽다 = Direct Access가 쉽다
✔️ 단점 :
- 파일을 할당할 때마다 저장할 수 있는 공간을 찾아야 함
- External fragmentation
compaction을 해줘야 함 (남은 free space를 하나의 continuous space로 합쳐주는 것) = 너무 별로 - 파일의 크기가 변할 수 있기 때문에 얼마나 파일이 커질 지 예측해야 함 = 근데 파일이 마냥 커지겠거니 할당하면 Internal fragmentation 문제까지
Non-Contiguous Allocation
✅ Linked Allocation
하나의 파일이 디스크 블럭의 링크드 리스트 형식으로 구성되어 있음
- 블럭은 다음 노드의 정보를 가지고 있고
- 디스크에 흩어져 있음
- 디렉토리에는 처음과 마지막 디스크 블럭의 정보가 담겨져 있음
✔️ 장점 : External Fragmentation ❌
✔️ 단점 :
- Sequential Access만 가능, Direct Access는 불가능함
Disk Access가 너무 많이 일어남➡️ 무조건 처음부터 시작해야 하기 때문에 - Reliability 🔽
하나가 고장나면 다음으로 넘어갈 수가 없음 - 포인터를 위한 extra space가 필요함
📎 FAT(File-Allocation Table)
Linked Allocation의 문제점들을 해결하기 위한 것
링크되어 있는 관계들(포인터)을 테이블로 메타데이터에 저장해둔 것
- 메모리에 저장 가능 = random access time이 향상됨
- reliability와 공간 효율을 보완하기 위함. 하지만 문제점 많음
✅ Indexed Allocation
블럭 하나를 잡아서 포인터(인덱스)만 모아놓은 것
디렉토리에는 인덱스값을 가지고 있는 블럭 하나만 저장한다
- 그 블럭은 자기 자신을 기준으로 인덱스값을 저장함
- 각각의 파일은 하나의 인덱스 블럭을 가지고 있음
✔️ 인덱스 블럭 :
디스크 블럭의 주소를 가지고 있는 어레이임
✔️ FAT와의 차이점
- FAT는 내가 몇번째 어디 블럭인지는 모르지만 다음 블럭은 뭔지 알고 있음
- 인덱스는 내가 어떤 파일의 몇번째 블럭인지 알고 있음
✔️ 장점 :
- External Fragmentation ❌
- Direct Access 도 ⭕️
✔️ 단점 :
- small file의 경우 너무 공간의 낭비(실제로 많은 파일들이 small)
- 반대로 파일이 너무 크면 한 블럭안에 인덱싱하기 힘듬
Allocation method Performance
✅ Contiguous Allocation 의 경우
디스크 블럭에 access 하는 데 딱 한번의 access가 필요함
Space efficiency가 좀 안좋을 뿐 Sequential, Direct access에 모두 좋음
✅ Linked Allocation 의 경우
Direct access ❌
✅ Indexed Allocation 의 경우
Sequential, Direct access에 모두 좋음 ➡️ 데이터가 커질 경우 여러가지 방안 마련 가능
🚀 결론
처음에는 Contiguous allocation을 사용하다가 파일의 사이즈가 커지면 Indexed allocation을 쓰는 것이 좋다
