유닉스 파일 시스템

특징

• 모든 것이 파일

• 아이노드 + Direct , Indirect 포인터

• 디스크 블럭의 위치정보를 포함한 uid ,gid ,time 등등 여러가지 정보를 아이노드에서 찾을 수 있다.

• 디렉토리는 파일명과 inumber의 쌍으로 이루어져 있다.

• 리눅스(미닉스)의 첫 번째 파일 시스템
  

• 슈퍼블럭 , 비트맵 , 아이노드 , 데이터 블럭

  • 판의 바깥쪽에 존재
  • 데이터는 안쪽 트랙에 존재

• 접근 특성 : inode => data 번갈아 수행

  • 디스크의 바깥쪽과 안쪽을 왔다갔다 해야함
  • Seek distance가 늘어남. => 성능 이슈

FFS (Fast File System)

• 데이터와 아이노드 같이 같은 시간에 접근되는 부분을 가까이 놓자.

  • 실린더 그룹 제안 => 같은 실린더는 seek time이 필요 없음

  

• 스토리지를 그룹으로 나눈다. 각 그룹마다 슈퍼블록 , 비트맵 , 아이노드 만듦

  • 디스크를 그룹별로 실린더를 나눈다. => inode , disk블럭을 같은 그룹
  • 슈퍼블록은 전체를 관리하는 메타데이터. 하나만 있어도 되는데 왜?
    • 너무 중요한 메타데이터라서 중복을 한다. (백업용)

• 스토리지를 파티션으로 나눈다.

• 파티션마다 서로 다른 파일 시스템

  • 부트 블럭 - 부팅관련 작업 , 파티션에 대한 정보를 가지고 있음. 스토리지 전체의 정보
    • 슈퍼 블럭 , 실린더 그룹
    • 슈퍼 블럭 카피(신뢰성 향상을 위함) ,그룹 디스크립터 , 비트맵 ,아이노드 , 데이터블럭

• I/O가 커짐. 512B => 4KB

• 파일의 크기가 작으면 낭비가 생김. 내부단편화 발생

  • 파편화하여 나눠줌

• UFS와 인터페이스는 동일하다(open read write). 내부적으로는 완전 다름

Ext2 FS

• 스토리지 => 부트블럭 , 블럭그룹(실린더그룹) ... 블럭그룹(N)

  • 슈퍼블럭은 그룹마다 중복 , 그룹디스크립터 , 비트맵 , 아이노드 , 데이터블럭

• 성능 향상

  • 아이노드와 관련있는 데이터를 실린더에 인접하도록 => 블럭 그룹
  • 선 할당 : 8블럭씩 미리 할당해준다. (랜덤I/O를 연속적I/O로)
  • Read-Ahead : 한 블럭을 읽어달라고하면 다음 블럭도 미리 읽는다.

• 확장성 지원

  • 파일시스템 사이즈 증가 , 파일 사이즈 증가, 디렉토리 내부의 이름 크기도 증가
  • fast 심볼릭 링크 , 마운트 옵션 지원 , 다양한 블럭 사이즈 지원
    • 하드링크(A와 B가 같은 아이노드를 가리킴) , 심볼릭 링크(각자 다른 아이노드 , 링크를 통해 정보에 도달)

  

• 부트블럭 : 512 + 512

• 슈퍼블럭 : 1024

• 1block : 1KB

FFS/Ex2 Issue

• 가까운 정보는 가까이에

• 실린더 그룹 / 블럭그룹
  ==> 그룹 사이즈를 얼마나?
  ==> 그룹 사이즈가 너무 크면 거리가 멀어짐. 너무 작으면 하나에 들어갈 파일의 개수가 제한.
  ==> 기본적으로 128MB

• 어느 블럭 그룹에 할당할 것?

  • 어느 그룹에 할당할 지?

  • 3가지 규칙

    • 1. 디렉토리는 실린더 그룹중에 inode가 가장 많은 곳에 넣자(로드밸런싱)
    • 2. 파일이 속해있는 디렉토리가 존재하는 그룹에 넣자.(네임스페이스 로컬리티)

    

• 공평한 할당 vs FFS 할당

• 만약 128MB를 넘게된다면?

• Rule3 : 한 그룹에서 한 파일이 어느정도 차지하면 다른 그룹에 쓰여지도록 한다.
  

• seek time이 발생할 수 있음

• chunk size : 키우면 좀더 많은 %를 i/o할 수 있다. 큰 파일이 한 그룹을 모두 차지하도록

• chunk size를 얼마나 할당하냐에 따라 네임스페이스 로컬리티와 Amortization(Seek-time을 감추는 것) 과의 상충관계