파일시스템

• 파일 디렉토리
• 데이터, 메타데이터

메타데이터

• 파일이나 파일시스템을 관리하기 위해 사용되는 정보

• 슈퍼블럭 : 파일시스템을 관리 (크기,블럭 사이즈,아이노드 위치, 루트 디렉토리 위치 , 이용률) : 파일시스템에 하나만

• 아이노드 : 파일의 속성(읽기 가능, 쓰기 가능, 사이즈) 관리 - 파일마다 하나씩 만들어짐

  • 파일에 속해있는 디스크블럭의 위치 정보 관리

• 비트맵 : 사용가능한지 사용중인지 구분 , 관리 (데이터를 위한 or inode를 위한 비트맵)

• EXT2(그룹 디스크립터), EXT3(저널) FAT(FAT), LFS-(segment) // 파일시스템(메타데이터)

간단한 파일시스템 예시

• 0번 ~ 63번까지의 디스크 블럭
• 새로운 파일시스템을 만드려고 한다. => 메타데이터를 만든다.
• 8번 ~63번은 데이터 영역
• 3~7번은 inode 관리 // 256바이트 per inode , 2^8 , 디스크 블럭 하나당 4K
  • 16개 존재 가능 256 x 16 = 4096
  • 이것을 3~7번 5개의 블럭을 사용하니까 16 x 5 = 80개의 inode가 존재한다.
• 아이노드 비트맵 / 데이터 비트맵은 앞에 놓고
• 슈퍼블록은 0번에 위치한다.

• 만들어진 파일시스템

inode

• 간단한 파일을 관리하기 위한 메타데이터

• mode : read / write / 실행

• uid : 생성한 사용자가 누구?

• size : 파일 크기

• time : 시간 정보

• gid : 그룹 id

• link.count : 하드링크, 소프트링크 개수

• blocks : 얼마나 많은 디스크 블럭이 할당?

• flags : 여러 플래그들

• block : 파일에 속해있는 디스크블럭들의 포인터

• Direct blocks vs Indirect Block

  • Direct : 데이터를 직접 가리킴 (최대 12개)
  • Indirect : single double triple, Index(또 다른 블럭을 포인터로 가리키는 것)를 가리키고 인덱스 블럭의 Lv에 따라 싱글 , 더블 , 트리플이 정해진다.

• Direct bloack 개수 x 4K x 1024

• InDirect block = 개수 x 1024 x N x 4K ( N = Index )

• 작은 파일 , 큰 파일 모두 효과적으로 지원 가능

• 작은 파일 : 다이렉트 => 성능 향상 (인덱스 필요X)

• 큰 파일 : 인다이렉트

• ex) hello.c를 root dir 아래에 만들었다. file size = 7K
  ==> root라는 dir와 hello.c 라는 2개의 파일이 만들어진다.

  • 8~63 : data
  • 3~7 : inode
  • 1,2 : bitmap
  • 0 :슈퍼블럭

• 아이노드 0번(root) , 데이터노드 8번 (아이노드가 포인팅함)

• 아이노드 1번(hello.c), 디스크블록 9,10번 (7K = 4K + 3K)
  . : 자기자신 ( 0 - 아이노드0번)
  .. : 부모 디렉토리 (부모도 동일)

if) 만약에 hello.c를 컴파일한다면?

• hello.o 가 70KB
• inode 0,1이 찼기때문에 2번을 할당
  • 디스크블럭 할당 : 70KB => 18개의 디스크 블럭 필요
  • Direct block이 12개밖에 없기 때문에 Indirect를 사용해야함
  • 나머지 6개는 Single로 가리켜야함.
  • Single을 사용하기 위해 Index블럭이 필요함.
    • ==> 18 + 1개의 디스크 블럭이 필요

파일시스템에서의 read

Issue 1) hello.o의 inode를 어떻게 찾을 것인가? root부터 찾기
Issue 2) 오프셋이 5000이라면 어느 디스크 블럭을 이 상태에서 읽어오게 될까?

5000 % 4096 = 몫 1(Index역할) 나머지 904
==> 0부터 4096은 첫 번째 디스크 블럭 , 그 후는 두 번째 디스크 블럭 + 904만큼 => 5000

디렉토리

• 파일이름과 아이노드의 쌍

Free Space

• 비트맵을 보고 할당
  1 : 사용중
  0 : 없음

접근 특성 및 최적화

조건 ) /foo/bar size 12KB open , read data and close it

• 파일시스템은 어떻게 접근하게 될까?

  • 세로 : 시간 , 가로 : 파일시스템 구조

  • Open : 1)루트의 아이노드 찾아감 , 2) 루트 데이터 읽음

    • foo가 있는지 확인
    • 3)foo inode 읽음, 4) foo data읽음
    • 5)bar inode 읽으면 open 완료

  • Read : bar의 크기 =>12KB (디스크 블럭 3개 ==> read 가 3번 진행됨)

    • 6) bar inode 읽음 , 7) bar data 읽음
    • 8) 다시 쓴다. 읽고 나면 마지막으로 엑세스 한 시간이 바뀐다. inode는 last access time을 기록해야한다.
    • 반복

  • Close : 관련된 자료 구조의 fd 할당 해제

1. 루트 아이노드, 데이터 읽기
2. 푸 아이노드 , 데이터 읽기
3. foo 아래 bar가 없는걸 확인. => 비트맵 읽기, 0인 아이노드 할당
4. bar 만듦, => 7위치. 8.9 읽었다 쓴다.
5. 10. foo의 inode가 바뀌었으니 쓰인다.
6. 이제 12kb를 쓴다.
   ==> write 3번 발생
   7 . bar 아이노드를 읽고(위치 파악) 데이터 비트맵을 읽고 아이노드 바꾼다.
   데이터를 썼으니 아이노드를 바꿔야한다.
   ==> I/O 5회 x 3 ==> 15회 I/O 발생

캐시

• 스토리지는 너무 느려서 DRAM에 저장하고자 함 ==> 캐싱
• 지역성 : 특정 데이터가 빈번하게 읽힌다.
  • 시간 지역성 : 최근에 접근된 데이터는 다시 접근 된다.
  • 공간 지역성 : 한 부분이 접근되면 그 부분이 다시 접근 된다.
• 동적 캐시 사이즈를 조절하기도 함

write buffering (쓰기 지연)

• 각각의 write를 한번에 한다.
• 임시 파일은 즉시 지운다.

• 지연 쓰기를 하면 bar inode 쓰기의 마지막만 수행해도 된다.

• data bitmap도 마지막만 ==> 총 5회의 write를 안해도 됨

• 캐싱, read를 처음만 읽고 나머지 소거 => 총 5회의 I/O 줄임

==> 중간에 전원결함 발생시 데이터 로스 발생
===> fsync() 사용으로 해결