리눅스 커널 파일 시스템 - F2FS
F2FS
위 발표자료를 보면서 공부해보자.
Log-structured File System (LFS) fits well to FTL devices.
data와 metadata를 연속적으로 "쓰기"한다.
논문을 봐야 이해가 될 것 같다. 논문은 2015년이다.
https://www.usenix.org/system/files/conference/fast15/fast15-paper-lee.pdf
문제점:
Frequent random writes --> internal fragmentation --> I/O latency, device lifetime에 악영향
해결책:
Log-structured file system (LFS)과 copy-on-write (CoW) 결합
예를 들어 BTRFS파일시스템은 NAND flash SSD에서 성능이 잘 나올 것임 - 하지만 Flash storage에 대한 고려가 부족하여 성능과 lifetime이 아주 좋지는 않을 것임.
LFS
기존 데이터를 덮어쓰지 않고 새로운 공간에 기록 후 추후 Garbage Collection (GC) 한다. random/sequential write에는 잘 맞지만 sequential read 시에는 성능 떨어질 수 있음.
CoW
수정이 일어나면 기존 데이터를 덮어쓰지 않고, 새로 복사본을 만들어 그 복사본에 수정하는 기법. 데이터 일관성 유지(crash 나도 기존 데이터 존재함)에 도움이 된다. 그리고 overwrite에 취약한 SSD에 좋다. (예시: Btrfs)
일관성 유지 측면:
1. 파일 A가 block #100 ~ #110 차지
2. 파일 A 일부 수정 요청
3. 파일 시스템은 block #100 덮어쓰지 않음
4. 대신 block #200에 새로 쓴 뒤, inode를 block #200으로 바꿈
5. crash 나도 block #100 그대로 살아있음
위 crash 문제는 ext4 파일 시스템에서도 Journaling으로 해결 가능하다. 하지만 성능 때문에 ext4 파일 시스템의 journaling 기본 모드인 ordered 모드를 사용한다면, overwrite 중 crash 문제는 해결할 수 없다.
논문을 통해 배우기
OSDI 2025에 나온 F2FS 관련 최신 논문: Decentralized, Epoch-based F2FS Journaling with Fine-grained Crash Recovery
Paper: https://www.usenix.org/system/files/osdi25-cui.pdf
Slide: https://www.usenix.org/sites/default/files/conference/protected-files/osdi25_slides_cui_yaotian.pdf
F2FS는 Crash recovery 시에 checkpointing에 의존하는데, 이는 file write를 blocking 하므로 system performance를 저하시킨다. 그리고 fully recover 하지도 못할 가능성이 있음 (coarse-grained checkpointing이기 때문).
본 논문에서는 이러한 한계를 돌파하기위해 F2FS를 위한 new journaling mechanism을 디자인함 - fine-grained crash recovery을 지원함. Journaling은 JBD2나 EXT4 같은 in-place-update filesystems에서 well-studied 됐지만, 이를 out-of-place-update filesystem인 F2FS에 그대로 적용해봤자 이득을 얻을 수 없음.
그래서 본 논문의 novel journaling technique인 F2FSJ에서는 F2FS with ordered journal mode를 제안함. F2FSJ에서는 metadata changes만 journal 됨 (data flushing 뒤에). 또한 Journal log를 inode에 embedding 시켜 metadata changes를 기록할 때 lock contention을 감소시킴.
또한 에폭(epoch) 기반 접근 방식과 데이터/컨트롤 플레인 분리 방식의 새로운 저널링(journaling) 메커니즘을 제안한다.
-
데이터 플레인은 inode별 변경사항을 저장하고,
-
컨트롤 플레인은 어떤 inode가 변경되었는지만 기록한다.
이러한 구조는 다음과 같은 두 가지 이점을 가진다:
-
분산 저널 설계가 가능해진다. → 각 epoch마다 inode 변경사항을 수집하여 커밋(commit) 가능.
-
저널 주기 전환 시 대기 시간이 거의 없다. → 즉시 새로운 epoch을 생성하여 다음 변경사항을 수용할 수 있다. (기존 저널 설계(JBD2 등)는 컨트롤 플레인과 데이터 플레인이 결합되어 있어, 저널 주기를 전환할 때 긴 대기 시간이 발생한다. 예를 들어 JBD2에서는 이전 트랜잭션이 커밋을 시작하면, 새로운 트랜잭션을 시작할 수 없다. 이는 데이터 생성(데이터 플레인)과 커밋 처리(컨트롤 플레인)가 묶여 있기 때문이다.)
반면, 기존 저널링 방식(예: JBD2)은 데이터와 컨트롤이 분리되어 있지 않아, 저널 주기 전환 시 반드시 대기 시간이 발생한다.
댓글
댓글 쓰기