운영체제의 기초 - 23. File System Organization

Big Picture on File System

File System이 제공하는 주요 기능

  1. Logical Address를 Physical Address로 변환

  2. 사용자의 데이터를 저장장치로부터 읽어오거나 저장장치에 기록하는 역할 

주요 File Access 패턴

  Sequential Access: File Pointer를 한 칸씩 움직이면서 파일의 내용을 읽는 방법

  Random Access: File Pointer를 임의로 이동하면서 파일의 내용을 읽는 방법

Volume (Logical Drive)

단일 File System으로 관리되는 저장 장치 상의 영역

Buffer Cache

최근 접근한 File의 Data Block 내용을 Main Memory에 저장해 두는 공간.

디스크로부터 한번 읽어온 파일의 내용에 다시 접근할 때, 빠르게 읽어올 수 있게 한다.

File Structures

디스크의 Fragmentation 문제 해결 방안

비연속적인 Block 단위로 Allocation을 수행

Linked File 구조에서 File C의 세 번째 블록을 읽는데 필요한 Disk Access 횟수

  1. File C의 Descriptor를 읽어온다. (File C의 첫 번째 블록의 주소를 알아냄)

  2. File C의 첫 번째 블록을 읽어온다. (File C의 두 번째 블록의 주소를 알아냄)

  3. File C의 두 번째 블록을 읽어온다. (File C의 세 번째 블록의 주소를 알아냄)

  4. File C의 세 번째 블록을 읽어온다.

70년대에 사용하던 방법임.

block 단위의 스토리지 allocation을 함.

File descriptor에다 그 파일이 가지고 있는 block들에 대한 pointer를 연결함

그래서 File descriptor 안에 index Array가 있음

단점: File descriptor는 일정한 크기를 갖는 descriptor들의 array로 구성한다.

즉, 그 안에 넣을 수 있는 index의 개수가 제한된다는 의미 (한 파일의 크기가 index의 개수만큼 제한이 된다.)

linked file구조와 indexed file구조 둘다 심각한 문제가 있즈만 indexed 파일 구조를 더 많이 사용한다.

그리고 indexed 파일은 UNIX OS의 기본 파일 구조다. (파일 사이즈에 대한 제한이 해결되었다는 의미겠죠?)

Inode에는 Attributes(metadata)와 할당된 block들의 index를 가지고 있음. 

index가 14개 저장되어 있음. 1~12 index는 direct block이라고 해서 바로 data block을 가리키고 있음

13번 index는 block을 가리키고 있는데 그 block안에 index가 또 들어있음 (tree형태로 contents의 개수를 늘릴 수 있음) _ 128개의 block을 가리킴

14번 index가 가리키는 block안에는 index가 있고 그 index가 가리키는 block에 또 index가 있고 그 안에는 data block이 있음

이와같이 14번 index를 Double indirect block을 만듦으로 인해서 파일 사이즈가 큰 것도 수용할 수 있게 됨

단점: Double indirect block 사용으로 인해서 파일 사이즈는 커질 수 있지만 데이타를 access하기 위해서 더 많은 시크가 필요하게 됨 

대부분의 크기가 작은 컨텐츠 파일들은 direct index로 다 처리가 됨 (오퍼레이션 커스트가 작음)

많이 존재하지 않고 덜 access되는 대형 파일들은 여전히 유지하면서 more 시크에 대한 비용을 지불함

이것이 현재까지 널리 사용하고 있는 파일시스템 structure 임

파일시스템은 device driver 사이에 buffer cache를 가지고 있다. 

buffer cache가 존재함으로 인해서 실제로 Read/Write한 횟수만큼 device driver가 동작하는 것이 아니라

많은 경우 device driver 에 가지 않고 buffer cache에서 hit가 나서 파일 operation들이 처리가 된다.

bit map operation

Disk block을 파일에 access할 때 가급적이면 근처에 있는 것을 할당하자 (근처 = 같은 실린더) 

plate는 다르더라도 같은 실린더 안에 block을 할당하면 시크는 피할 수 있음 (가장 비싼, 가장 느린)

그것도 안된다면 인접 실린더에 할당하면 됨 (이러한 3차원 structure를 반영해서 renewer sector array를 만든다. 

그리고 renewer sector array를 할당할 때는 가급적이면 몇개의 block이 continuous하게 있는 것을 할당합니다.

이렇게 되면 OS이 continuous한 block의 위치를 알아야 함

그 때 많이 사용하는 것이 Bit map임

Disk block들에게 전부 1bit를 map시켜 놓음. 그 block이 free하면 1이 할당되고 사용되고 있으면 0이 할당됨

Bit map은 디스크 스토리지에 allocation에 대한 지도라고 생각하면 됨

Bit Map을 사용한 디스크의 Free Block 관리

각 Bit가 디스크의 Block이 사용 중인지 아닌 지를 나타내는 Array.

HW/SW String Search 기법을 사용해 연속적인 사용 가능한 Block을 쉽게 찾을 수 있다.

결국 파일의 구조를 결정하는 요소는 뭐냐?

- Sequential access와 Random access 를 효율적으로 지원해야 된다.

- 작은 파일과 큰 파일을 모두 효율적으로 지원해야 된다.

Disk Space Management

Disk Space Management

File이 생성되거나 확장될 때, 어떻게 Disk Sector들을 File에 할당해 줄 것인가를 결정

Metadata: 유저들한테는 보이지 않지만 kernel이 각 파일 별로 관리하고 있는 공간

in-memory cache를 항상 유지하고 있어야 하고 시스템이 shutdown될때는 consistency(일관성)을 유지해야 한다.

Extend-based Allocation

Block들을 그룹으로 묶고 각 그룹에 Semantics(의미)를 부여함으로써 최적화를 달성하는 정책

Block단위로 allocation을 하게 되면 Sequential Read를 할 때 너무나 많은 시크가 발생하기 때문에 

좀 더 큰 단위로 할당하기 위해서 Extend-based allocation방법을 씀

directory안에는 파일의 이름과 파일 index number 가 들어있음

inode들이 만약 전부 흩어져있으면 # ls 하기 위해서 a lot of 시크를 해야 함

동일한 directory에 있는 inode들은 가급적 동일한 실린더 넣으면 좋겠죠

이런 여러가지 성능을 향상시키기 위한 heuristics를 생각해 볼 수 있음

block 단위의 allocation으로는 안되고 extend-based allocation이 필요하게 됨

Heap처럼 하는 것 (과거에 씀. 지금은 안씀) 왜냐 fragmentation 문제때문에

s5fs

- block-based allocation을 이용하기 때문에 grouping을 못시킴

- inode와 data block을 분리시켜 시크 operation이 많아짐

- 이러한 성능저하 요소들을 많이 가지고 있음

NFS

- 너무나 많은 파일시스템이 하나의 컴퓨터 안에 존재

LFS

- 디스크 스토리지의 크기가 커짐

---

출처 - http://snui.snu.ac.kr/ocw/index.php?mode=view&id=685

출처 - http://snui.snu.ac.kr/ocw/index.php?mode=view&id=686

출처 - http://snui.snu.ac.kr/ocw/index.php?mode=view&id=687