# S5FS
- System V File System
- 하나의 볼륨(하나의 disk drive, 하나의 partition)당 하나의 파일시스템을 갖음
- 하나의 파일시스템은 Stand alone 시스템 : 파일에 대한 모든 컨텐츠와 정보들이 하나의 볼륨안에 저장이 됨
- 하나의 partition에 존재하는 block의 크기는 512 bytes (512, 1024, 2048)
- Sector들의 linear array = block의 linear array
- Boot Area : 0번째 block에 위치하며, Boot Program을 저장하고 있음.
Boot Area에서 Boot Program을 메모리로 로드하여 하드웨어 디바이스를 부팅시킴
- Super Block : 볼륨에 대한 파일시스템의 모든 메타데이터.
- inode list
=> 전통적인 초창기 모델이므로 성능과 안정상에 문제를 가지고 있음
- 파일의 inode와 data block간의 물리적인 거리가 멀기 때문에 파일에 접근 시 과도한 Seek Operation이 발생
- Data Block의 할당/해제를 반복할수록 free block이 산재하게 되어 sequential block을 읽을 때 과도한 Seek Operation이 발생
- super block이 한곳에만 저장되어 있으므로 손상될 경우 파일시스템을 사용할 수 없음
- 컴퓨터 시스템에서 빈번하게 사용하는 operation에 최적화 되어있지 않음. 중구난방으로 흩어져 있음
# FFS
- UFS : Unix File System
- self-contained file system
- cylinder group이라는 개념을 도입
: 인접한 cylinder를 묶어서 그룹화, 지역적으로 비슷한 곳에 있는 정보는 같은 cylinder group에 저장
- cylinder group마다 super block을 가짐(super block을 여러개 두어 recoverry를 도모)
- block안에 fragment라는 더 작은 단위를 도입. fragment단위로 allocation
- 하나의 cylinder group에 저장하기 힘든 사이즈가 큰 파일들은 인전 cylinder group으로 넘어감. (48KB 이상이 되면)
<장점>
- seek optimization. 적절한 spreading으로 동일한 파일의 Block들이 멀리 떨어져 저장되는 것을 방지
- lotational Delay optimization.
: seek operation에서 sector를 읽으려면 disk driver에서 read request 만들어서 날려야 할 때, 2 sector가 지나가는 시간이 걸린다고 가정.
0번 sector를 읽고 1번 sector를 읽어야 할 때, 한번 resquest를 하면 2개의 sector가 지나가면 1번 sector를 읽기위해서는 다시 한바퀴를 돌아야 함.
=> 이런 문제를 방지하기 위해 lotational delay를 계산하여 sector에 저장하도록 함
- long file name의 지원. 256characters.
- symbolic links의 도입
- Disk quota 도입
<한계>
- sequential read의 한계
- crash recovery가 느려지는 문제 발생. disk storage의 block size가 굉장히 빠르게 증가.
=> 적절한 부팅 시스템을 무시하고 시스템을 power off하면 rebooting할 때 파일시스템의 inconsistency를 확인.
=> "fsck", file system check라는 command를 수행하는데 굉장한 시간이 걸림
=> log structured file system을 사용하게 됨
# LFS
: Log-structured File System
> Crash recovery의 필요
- 성능향상을 위해 inode cache를 가지는 구조에서 문제가 발생하면 disk의 inode의 값과 메모리의 inode값이 일치하지 않게 될 수 있음
- disk에 대한 operation은 transaction과 같아 synchronous write를 수행하게 됨
> fsck의 수행동작
- 시스템에 존재하는 inode들을 체크하여 used block들을 확인
- used block들의 구조에서 각각의 directory 별로 file contents를 모두 확인하여 파일의 inode를 확인
- inode indexdp mapping된 데이터가 제대로 있는지 확인. 찾을수 없는 파일이나 연결이 안된 디렉토리들...
- lost + found directory에 보내기
> LFS 구현
- 새로 생성될, 새로 추가될 정보만 파일의 정보 뒤에 붙이게 됨
- log : Operations나 values, redo/undo log,
- garbage collection : 어느 시점이 되어서 로그가 너무 방대해지면 sequential read operation이 굉장히 느려지게 됨
- group commit
- retrieval
# Disk Scheduling
- Request Queue : disk에 대한 I/O request를 저장하는 queue
- device drivers와 devices 사이에 request Queue가 위치
- device driver에 I/O Scheduler가 스케쥴링을 수행
- Request Ordering을 수행하여 시간을 줄임
FIFO/FCFS (x)
SSTF (x)
Scan like Elevator (x) => 양방향에 위치한 애들만 너무 불리해
Circular Scan (o)
> Flash memory 등의 경우에는 disk보다 더 복잡한 스케쥴링이 필요하게 됨
: bus share, multi processor, 공정의 여러 제약 등
'System > Etc.' 카테고리의 다른 글
git (0) | 2016.01.17 |
---|---|
FDT (0) | 2015.11.14 |
[OS 기초] File System (0) | 2015.11.05 |
[OS 기초] I/O Device와 Device Driver (0) | 2015.11.05 |
[OS 기초] Demand paging 3 - Trashing, Working Set (0) | 2015.11.04 |