파일시스템
- 파일 디렉토리
- 데이터, 메타데이터
메타데이터
-
파일이나 파일시스템을 관리하기 위해 사용되는 정보
-
슈퍼블럭 : 파일시스템을 관리 (크기,블럭 사이즈,아이노드 위치, 루트 디렉토리 위치 , 이용률) : 파일시스템에 하나만
-
아이노드 : 파일의 속성(읽기 가능, 쓰기 가능, 사이즈) 관리 - 파일마다 하나씩 만들어짐
- 파일에 속해있는 디스크블럭의 위치 정보 관리
-
비트맵 : 사용가능한지 사용중인지 구분 , 관리 (데이터를 위한 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 할당 해제
-
- 루트 아이노드, 데이터 읽기
- 푸 아이노드 , 데이터 읽기
- foo 아래 bar가 없는걸 확인. => 비트맵 읽기, 0인 아이노드 할당
- bar 만듦, => 7위치. 8.9 읽었다 쓴다.
- foo의 inode가 바뀌었으니 쓰인다.
- 이제 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() 사용으로 해결
