# 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

+ Recent posts