Chapter#24 FSCK and Journaling

Chapter#24 FSCK and Journaling

- Crash Consistency Problem

- File System Checker(fsck)

- Journaling

---

Crash Consistency Problem

Crash Consistency

file system data structure은 파워가 꺼져도 persist해야함

crash-consistency problem 발생 및 해결책

- fsck (file system checker)

- Journaling (wrire-ahead logging)

 

Crash Consistency Problem

open() > lseek() > write() > close() 작업을 한 경우

기존 file 크기는 1 첫 direct pointer가 4(Da)를 가리킴 나머지 3개는 null	Data bitmap 갱신 Inode 갱신 새로운 data block 할당(Db) > 두번째 포인터가 가리킴

즉, 아래 3개의 갱신이 일어남

1. One each of inode I[v2]

2. Data bitmap B[v2]

3. Data block Db

3개 중 일부만 실행되고 power off되는 경우 : file system은 funny(inconsistent) state로 남게 됨

 

Crash Scenario (case analysisㅠㅠ)

case 1a: Just data block Db is written to disk

- data는 disk에 저장되나, inode가 없음 > 쓰인적이 없는 경우로 간주됨

- consistency면에서 큰 문제는 아니다

case 1b: Just updated inode I[v2] is written to disk

- inode가 disk address (5,Db)를 가리킴 > Db가 안쓰였기에 엉뚱한(garbage) data를 가리킴

- File-system inconsistency!

case 1c: Just the updated bitmap B[v2] is written to disk

- bitmap이 block 5가 할당되었다고 가리킴 > inode값은 없음

- File-system inconsistency! : block 5는 사용 못하는 공간이 됨

case 2a: Just inode I[v2] and bitmap B[v2] are written to disk

- metadata는 consistent, 하지만 block 5는 garbage data를 가짐

case 2b: Just inode I[v2] and data block Db are written to disk

- Inconsistency between inode and old version bitmap : 해당 block이 free로 간주되어 덮어씌워질 가능성 존재

case 2c: Just bitmap B[v2] and data block Db are written to disk

- Inconsistency between inode and data bitmap : 파일이 어디 있는지 알 수 없음

 

요약 : 

세 작업이 atomically 완벽히 수행되거나 아예 안되어야함

하지만 쉽지는 않다!

---

File System Checker (fsck)

fsck : Unix tool. inconsistencies 확인 및 repair

- check : super block, free block, inode states, inode links, etc

- file system이 mounte되기 전에 실행 : fsck도는 동안 file-system activity 활동 안함 > 완료되면 consistent해짐

- 모든 문제 해결은 안됨 : ex case 2a : metadata는 consistent한데 block이 garbage data로 차있는 경우

- 즉, metadata가 internally consistent하도록 만들 뿐

 

Inode state

- each inode is checked for corruption or other problem e.g. type checking(regular file, directory, symbolic link, etc)

- 문제가 있다고 생각되면 fsck가 지움

Free blocks

- scans inodes, indirect blocks, double indirect blocks

- Inconsistency between bitmaps and inodes : inode 정보에 따라 resolve e.g. case 1c, 2b

Directory checks

- fsck는 user file 정보를 이해하지 못함

- 각 directory contents에 대해 additional integrity check수행

ex) . 과 .. 이 first entries인가, directory의 각 inode들이 잘 할당되어있는가 등등

 

아무튼 엄청 느리다!

---

Journaling

Journaling (WAL : Write-Ahead Logging)

overwriting 전에 little note 작성("write ahead" part. = log) > crash가 발생 시 log 확인 후 재시도

- crash 이후에 무엇을 바꿔야할지 entire disk scan하지 않고도 알 수 있다.

 

ext2

ext3

 

Journal write

TxB : Transaction begin block

- transaction identifier(TID)같은걸 가짐

- 중간의 3개 block은 exact content : physical logging

TxE : Transaction end block

- Marker of end of transaction

- TID를 가짐

 

Checkpoint

저널 영역에 임시적으로 기록된걸 원래 위치로 copy하는 것 : checkpointing

 

Scenario

case 1 : Transaction each one at a time

- (TxB, I[v2], B[v2], Db, TxE)를 순서대로 다 쓴다

- 느림

case 2 : Transaction all block writes at once

- (TxB, I[v2], B[v2], Db, TxE)를 동시에 쓴다

- disk도 스케쥴링 따라 작동하므로 TxE가 써졌는데 crash가 일어나 내용물이 안써질수도 있음

=> TxE를 빼고 동시에 쓴 후 확인하고 TxE씀 (Journal Commit)

 

Revised Operation :

1. Journal write : write TxB, all pending data, metadata updates

2. Journal commit : write TxE

3. Checkpoint : write pending metadata and data updates to final location

 

Recovery

crash가 transaction이 log에 적히기 전에 발생 : skip

crash가 transaction이 log에 적힌 후 & checkpoint 완료 전에 발생 :  recover

- scan log > disk에 commit된 transaction 찾아보기 > transaction 재시행

 

Making the log finite

log가 가득차면 두가지 문제 발생

- the larger the log, the longer recovery will take

- no further transactions can be committed to disk = making file system useless

해결 : log data structure을 circular하게 이용

- Journal super block를 이용해서 oldest/newest transaction log를 marking

 

Revised Operation :

1. Journal write : write TxB, all pending data, metadata updates

2. Journal commit : write TxE

3. Checkpoint : write pending metadata and data updates to final location

4. Free : mark transaction free in journal by updating journal superblock

---

학교 강의를 토대로 개인 공부 목적으로 작성되어 오타가 및 오류가 있을 수 있으며, 문제가 될 시 삭제될 수 있습니다.