Fast File System

그전에 File System Implementation에서 살펴보았던

 

와 같은 구조는 간단하지만 매우 안 좋은 성능을 가지고 있습니다.

• Problem 1: Positining cost가 높습니다.
  • Data가 Disk에 저장되어 있다면 AccessTime이 데이터가 조각나있을 수록 높을텐데 이를 고려하지 않은 시스템입니다.
  • Expensive한 Positioning Cost를 가집니다.
    • 예를들어 Data Block과 파일은 서로 자주 접근해야하는 관계임에도 불구하고 매우 멀리 떨어져있습니다.
    • 이럴 경우 Seek Time이 늘어납니다.
• Problem 2: Fragmentation이 이것을 더 심각하게 만듭니다.
  • 만약 데이터 A-B-C-D가 순서대로 저장되어 있었더라도 B와 D가 지워진 후 E를 저장하려면 E가 조각나있는 상태가 됩니다.

그래서 FFS(Fast File System)을 사용하게 됩니다.

FFS는 "Disk aware"한 방식으로 기존의 Access method는 내버려둔 상태로 Data Structure(=internel implementation)만 바꾸는 방식으로 구현됩니다.

 

FFS는 disk를 Cylinder Group(=Block Group)으로 나눕니다. Cylinder는 물리적인 Disk의 Surface에 담겨 있는 Track들을 의미합니다.

 

이 방식은 Seek performance를 개선하기 위해 고안된 것으로, 같은 파일을 같은 그룹에 넣습니다.

즉, 기본적인 Policy는 관련있는 데이터를 같이 둔다 입니다.

• Policy 1: Directory는 어디에 두어야 할까요?
  • Cylinder Group중 할당된 디렉토리 수가 적고, inode number가 많이 남는 곳을 선택합니다.
  • Directory data와 innode를 같은 그룹에 저장합니다.
• Policy 2: File은 어디에 두어야 할까요?
  • 모든 파일을 그것이 속한 디렉토리에와 같은 group에 배치합니다.

그러면 가까운 것은 더 가깝게 배치되죠?

그러나 Issue 들이 있습니다.

• Group이 너무 빨리 찹니다.
• 이게 인접할 거라는 보장이 존재하지 않습니다.
  • SEER Trace : 얼마나 인접해 있는지를 체크하는 Trace입니다.
• Large File의 경우 어떻게 배치해야할까요?
  • Large file은 Cyclic Group의 block 전체를 채웁니다.
  • 그것은 related된 파일을 같이 배치할 수 없습니다.
  • 그래서 Large File은 chunk로 나누어 disk전체에 나뉘어저 배치됩니다.
    • Chunk사이즈는 충분히 크게 해주고, 이에 따르는 Overhead는 데이터를 전송하는데 사용하여 상각(armortization) 시켜줍니다. 즉 전송 시간, Seek Time의 비율을 조정해 주는 것입니다.
  • Inode는 한개의 Cyclic Group에만 저장하고 Data는 분산시켜 줍니다.