Hard Disk
•
array of sector의 추상화이다
•
한 섹터는 512바이트나 4096 바이트이다
•
크고, 싸고, 영구적이고, 느리다
•
Cylinder-Header-Sector Scheme
◦
각 블럭은 cylinder, head, sector로 특정된다
•
Logical block addressing (LBA) Scheme
◦
SCSI에 소개된거임
◦
Disk는 블럭의 논리적 배열로 추상화됨
◦
LBA(Logical block address)로 다뤄지고, Disk는 이 LBA를 물리 장소로 매핑함
•
HDD 퍼포먼스는
◦
실린더 찾기(r 조절)
◦
rotation delay
◦
transfer 타임이다
•
이 디스크 스케쥴링도 해야한다.
◦
seeks이 비싸다.
SDD
•
block의 집합이다
•
각 블럭은 페이지로 이루어져있다.
•
블럭이나 페이지의 크기는 기술에 따라 다르다.
NAND 타입
•
SLC
◦
single level cell
◦
1 bit/cell
•
MLC
◦
multi level cell
◦
2 bits/cell
•
TLC
◦
triple level cell
◦
3bits/cell
•
셀이 많아질수록, 용량은 많아지는데 느려짐
NAND constraints
•
No in-place update
◦
같은 위치에 덮어쓰기 하지 못한다
◦
다른 위치에 쓰고, 기존 주소를 새 주소로 매핑해야한다.
◦
여기서 매핑은 논리 주소를 물리 주소로 바꾸는 걸 의미
◦
이 관리는 SSD 컨트롤러 내부에 FTL이 관리
•
비트 에러
◦
ECC를 사용해서 감지
•
불량 블록
◦
이 블록을 우회하도록 해야함
•
수명이 있다
Flash memory
•
NAND는 1을 0으로 바꾸는건 가능
•
하지만 0을 1로 바꾸려면 전체 삭제가 필요하다
◦
전체 삭제라고 하면 그냥 한 블록을 전부 1로 만드는 것임
•
bulk erase
◦
page 단위로 쓴다
◦
지우는 단위는 블록이다
page mapping
Flash는 한 번 쓴 페이지를 덮어쓸 수 없기 때문에, LBA랑 PPN을 매핑하는 테이블이 필요하다.
•
invalidate 된 친구들은 flash controller가 동작해서 지운다.
File System
File
•
데이터 묶음
•
메타 데이터는 inode라는 타입으로 저장
◦
type
◦
uid
◦
rwx
◦
size
◦
blocks
◦
addrs[N]: 파일 데이터를 저장한 디스크 블록 번호 리스트
Directory
•
내부에는 파일 이름, inode 번호 쌍이 들어있다.
Design 이슈
•
메타데이터에 정보를 어떻게 저장하지?
•
파일 이름에서 메타데이터를 어떻게 찾지?
•
메타데이터, offset에서 데이터 블럭을 어떻게 찾지
•
메타데이터랑 데이터 블럭을 어떻게 관리하지
•
crash 시 어떻게 파일 시스템을 recovery 하지
General
•
파일 시스템은 마운팅이 되어야한다.
◦
서로 다른 파일 시스템이 같은 트리에 마운트 될 수 있다
•
하드 링크 vs symbolic links
◦
하드 링크는 pathname이 같은 inode 숫자를 쓴다
◦
뭐가 original인지 모름
◦
inode는 하드 링크의 수를 저장함
◦
파일 삭제는 그 수를 줄이는 것 뿐이고, 그게 0이 되면 inode가 사라짐
◦
심볼릭은 그냥 바로 가기 같은 거임
▪
다른 파일에 대한 레퍼런스를 가지고 있을 뿐이다.
▪
그건 이제 절대 경로나, 상대 경로 같은 pathname이다.
•
파일 시스템은 쓰기에 대해서 메모리에 버퍼로 일단 남긴다
◦
fsync()는 dirty data를 디스크로 방출함.
◦
그리고 메타데이터도 같이 내보낸다
◦
fdatasync는 바뀐 메타데이터는 안 내보낸다.
•
Read Ahead (prefetch)
◦
파일 시스템은 파일 캐시로 데이터 블록을 먼저 읽어온다.
◦
필요할 거 같으면 먼저 들고오는 식
◦
spatial locality를 이용
•
Consistency/Sharing
◦
Unix 개념
▪
프로세스 간에 공유가 됨
▪
같은 시간에 열려있으면 다른 사람들한테 다 보인다
◦
AFS Session
▪
파일을 열고 있는 동안 즉시 반영되지는 않는다
▪
닫은 후에야 보임
Implementation
VSFS
•
very simple file system
◦
디스크를 블럭으로 나눈다
◦
블럭 사이즈는 sector size의 multiple임
◦
블럭은 OS에서 사용하는 단위, 섹터는 디스크에서 사용하는 단위
◦
일부 비율은 파일 시스템 메타데이터를 위해 남겨진다.
•
inode의 사이즈는 고정되어있다.
◦
만약 한개당 256B라면, 한 4KB 블럭당 16개의 inode를 가지고 있다
◦
5개의 블럭에는 80개의 inode가 있는건데, 이게 최대 파일의 수다
•
bitmap 블럭이 있어서 각 데이터/inode 블럭이 유효한지 안 한지 알 수 있다
•
슈퍼블록이 있다
◦
파일 시스템의 메타데이터를 담음
▪
파일 시스템 타입
▪
블럭 사이즈
▪
전체 블럭 수
▪
전체 아이노드 수
▪
등등
Allocation Strategy
•
파일을 디스크 블록에 어떻게 매핑하지
◦
연속적으로 배정
▪
horrible external fragmenation
▪
파일을 옮기지 않고서는 grow 하지 못한다
▪
sequential access에는 성능이 좋음
▪
random access도 간단한 계산하면 잘 됨
▪
IBM OS/360
◦
linked list로 배정
▪
TOPS-10, Alto
▪
랜덤 액세스가 엄청 느리다
▪
no external fragmentation
◦
File allocation Table
▪
랜덤 엑세스 성능을 늘리기 위함으로, file allocation table을 만들어서, 그 다음 링크 블록이 어디에 있는지를 적어놓음
▪
메인 메모리에 유지
▪
큰 파일 시스템에 scalability 안 좋을 수 있음
◦
Indexed allocation
▪
각 파일마다 fixed size block을 할당함
▪
어떻게 블록을 연결할 것인가에 대한 방법 중 하나
▪
파일은 여러 개의 고정 크기 블록에 나누어 저장됨
▪
인덱스 블록이 따로 존재, 이 인덱스 블록 안에 해당 파일이 차지하는 데이터 블록들의 번호를 배열로 저장
▪
메타데이터 오버헤드가 있음
▪
인덱스 블록 크기에 따라 파일 최대 크기가 제한될 수 있음
▪
no external fragmentation, 랜덤 접근 지원
◦
multi-level indexing
▪
hierarchy를 가진다
▪
direct pointer랑 indirect pointer를 가짐
▪
필요없는 포인터에 대해서는 공간 낭비 없음
▪
추가적인 disk read를 할 수 있음
▪
unix FFs, Linux Ext2/3
◦
extent-based allocation
▪
파일마다 여러 개의 연속된 공간을 확장함
▪
Extent: 여러 개의 블록들을 하나의 단위로 묶은 것
▪
연속 범위로 저장한다
▪
b+tree 처럼 저장
Directory
◦
Table or linear list
▪
linear search를 해야함
◦
Tree
▪
Sort가 되있을 수 있음.
◦
Hash Table:
▪
빠르지만 파일이 늘어날 수록 scalable 해야한다
Crash Consistency
•
FSCK
◦
FSCK는 파일 시스템이 마운트 될 때, 모든 consistency를 체크한다
▪
Inode bitmap consistency
▪
Data bitmap consistency
▪
Inode link count
▪
duplicated/invalid data block pointers
▪
other integrity checks for superblock, inode, and directory
◦
근데 너무 느리디ㅏ
•
Journaling
◦
파일을 직접 반영하기 전에 로그를 남긴다
◦
이 로그를 보고 redo하거나 아예 undo하거나
◦
