Fast File System

UFS (유닉스 파일 시스템)

- 레이아웃

부트 섹터

슈퍼블록

비트맵

Inode

유저 데이터

심플하고 사용하기 쉬움

보기에는 괜찮으나, Seek distance 같은 걸 고려하면 성능에 문제가 있고,

데이터 하나를 write하는데에 상당히 많은 I/O가 발생

-> 성능 문제

-> 일관성 문제

 

성능적으로 굉장히 나쁨

UFS의 구조대로면 디스크 바깥쪽에 inode가 쭉 쌓이고 안쪽에 유저 데이터가 존재

inode와 데이터 접근을 번갈아하면서 디스크 시크가 많이 발생하게 됨

=> FFS .. inode와 유저 데이터를 가까운 곳에 놓겠다.

 

같은 실린더 그룹에 있는 데이터는 시크 디스턴스가 필요 없음

혹은 가까운 실린더에서는 시크 디스턴스가 적게 필요

* Ext2/3/4에서 사용되는 개념.. 블록 그룹이라 부름

** 실린더 그룹: 중심으로부터 같은 거리에 있는 다른 서페이스들에 있는 트랙들의 집합

 

FFS 디테일

파티션 -> 여러개의 실린더 그룹으로 나뉘어짐

각 그룹마다 슈퍼블록, 비트맵, inode를 세분화해서 가짐

* 슈퍼블록이 여러개인 이유 - 신뢰성 (하나가 깨져도 다른 그룹의 슈퍼블록 사용 가능)

 

inode와 데이터가 같은 그룹에 있으면 시크 디스턴스가 감소

 

UFS와 구현 방식은 다르지만 외부에서 볼 때는 같은 인터페이스 (오픈 리드 라이트)

 

 

FFS 할당

관련된 데이터를 밀접하게 배치시킴

inode와 데이터, 파일과 관련 디렉토리를 같은 그룹에 넣고자 함

 

할당 룰

1. 가능한 디렉토리는 프리한 inode가 가장 많은 그룹을 선택한다. (덜 붐비는 곳)

- 로드 밸런싱을 위한 규칙 .. 페어니스 고려

 

 

2. 파일이 만들어지면 inode와 데이터는 그 파일이 속하는 디렉토리가 존재하는 그룹에 만든다.

- 어떤 파일이 어느 그룹에 들어간다고 결정되면 디렉토리의 다른 파일을 같이 읽는 경향이 있기 때문

- 네임 스페이스 로컬리티 (특정 파일이 참조되면 관련된 파일들이 함께 참조될 가능성이 높다)

 

* 시간적 지역성 - 최근에 사용한 건 곧 다시 사용할 가능성이 높음

* 공간적 지역성 - 어떤 지역이 참조되면 그 근방은 다시 참조 (배열, 스택 등)

 

3. 어떤 파일이 그룹에 들어갈 수 있는 블록의 개수(청크)를 제한함

- 어떤 파일을 만드는데 사이즈가 너무 크면 혼자 공간을 다 차지할 수도 있음

-> 같은 위치에 들어가면 좋은 파일들이 다른 그룹으로 가게 될 수도 있음

 

장점: 파일들 간 로컬리티

단점: 한 파일에서의 로컬리티 손해

 

예시

시크타임 10ms, 대역폭 40MB/s

1. 그룹당 청크 4MB 가정

4MB / 40MB/s = 100ms

10 / 110 -> 유저 데이터 전송을 위해 90퍼센트의 시간 사용, 시크를 위해 10퍼센트 사용

 

2. 그룹당 청크 400KB

0.4MB / 40MB/s = 10ms

10 / 20 -> 유저 데이터 전송을 위해 50퍼센트, 시크를 위해 50퍼센트

 

청크 사이즈가 크면 시크 오버헤드를 그만큼 감출 수 있음

-> Amortization (부하가 걸리는 일이 있는데 일하는 시간에 비해 최대로 적게 만들어 감추는 것)

 

 

FFS 특징

1. 실린더 그룹

inode와 유저 데이터를 같은 실린더 그룹에 넣고,

네임 스페이스 로컬리티를 활용해서 시크 타임을 줄임

 

2. 디스크 블록의 크기를 더 크게 함

UFS 때는 디스크 블록의 크기가 섹터 크기와 동일했음 (512B)

FFS는 4KB 읽고 시크 ,, 반복

 

장점: 시크를 줄이고 전송을 더 할 수 있음 -> 대역폭 활용을 더 잘함

단점: 내부 단편화

* 단편화는 외부 단편화와 내부 단편화가 있음

외부 단편화는 어떤 데이터들이 있는데 불연속적으로 있는 경우

프리 스페이스는 모여있는게 좋은데 띄엄띄엄 있게 되면 외부 단편화 -> 많은 시크 유발

 

내부 단편화는 어떤 디스크 블록을 할당했는데 다 사용하지 않고 일부는 사용하지 않게 되는 경우

디스크 블록이 4K라 하면 1K 필요해도 4K 단위로 주게 됨

이 3K 부분을 보고 내부 단편화되었다고 함

보통 디스크 블록 절반 .. 2K 가량 낭비

 

3. 서브 블록(프레그먼트) 얼로케이션

내부 단편화 해결을 위해 사용

큰 파일은 큰 디스크 블록을 주고, 파일이 작으면 디스크 블록을 프레그먼트로 나누어 줌

한 프레그먼트가 1K라 할 때, 1K 달라고 하면 프레그먼트 하나 주면 됨

 

4. 파라미터라이제이션

디스크의 특성을 보고 디스크 블록의 배치를 다르게 함

연속적으로 1, 2, 3번 블록을 요청 시,

리퀘스트 2가 디스크에 도착했을 때 이미 헤드가 지나쳤을 수도 있음 (읽은 내용을 호스트에게 보내야 하는 시간 때문)

=> 디스크 블록을 하나 건너 뛰어서 해서 트랜스퍼 시간을 위한 여유를 줄 수 있음

(Parameterized placement)

* 최근 디스크는 트랙 버퍼를 써서 해결함

 

그외

심볼릭 링크 (다른 파일 시스템 간 링크 가능), 원자적인 rename, 긴 파일 이름