JFFS : The Journaling Flash File System

1. JFFS : The Journaling Flash File System David Woodhouse Red Hat, Inc. 2006.01 박성환 (shpark@dislab.hufs.ac.kr)

2. 목 차 • 서론 • 플래시 메모리 • FTL (Flash Translation Layer) • JFFS Version 1 • 저장 형식 (Storage Format) • 연산 (Operation) • 가베지 컬렉션(Garbage Collection) • 운영법 (Housekeeping) JFFS : The Journaling Flash File System

3. 서 론 • JFFS (Journaling Flash File System) • Log-structured File System on Flash Devices in Embedded System • JFFS2 • 압축과 효율적인 Garbage Collection을 사용 JFFS : The Journaling Flash File System

4. 플래시 메모리 • NOR 와 NAND type • NOR : 직접 접근 가능 • NAND : 블록과 섹터로 접근 가능 • 블록단위로 소거(Reset)가 가능 • 블록은 약 100,000번 소거시 생명주기를 다함 • 때문에 소거 횟수 평준화(Wear Leveling)가 필요함 • 논문에서 정의한 단어 • Page : 512 bytes • Out of band : 16 bytes • 메타데이터나 에러 정정 코드등을 저장 JFFS : The Journaling Flash File System

5. FTL (Flash Translation Layers) • 데이터의 수정은 해당블록의 소거연산이 선행됨 • 때문에 FTL이 중간에서 효율적인 연산으로 변환하는 역할을 함 • FTL에서 소거 횟수 평준화도 제공 가능 • 이런 FTL이 사실상 Journaling File System의 모습이 됨 JFFS : The Journaling Flash File System

6. JFFS Version 1 JFFS는 Embedded와 베터리 전력을 사용하는 System에서 신뢰적인 연산과 예기치 못한 System ShutDown을 처리하기 위해 디자인 됨

7. JFFS 구조 • JFFS는 Buffer Cache를 사용하지 않음 JFFS : The Journaling Flash File System

8. 저장 형식 • Original JFFS는 순수한 LFS(Log-Structured File System)이였음 • 데이터나 메타데이터를 가지는 Node는 순차적으로 저장 • JFFS1에서 Log에는 한가지 타입의 Node만 존재 • struct jffs_raw_inode • 각 node는 단 하나의 inode에만 연관됨 • Header • inode들의 번호를 가지고 있음 • inode를 위한 현재 File System의 메타데이터 • 데이터의 총크기의 변수 JFFS : The Journaling Flash File System

9. jffs_raw_inode JFFS : The Journaling Flash File System

10. 저장 형식(Con’t) • inode와 연관된 모든 node들 사이에는 순서가 있음 • 모든 node들 사이에선 version번호로 순서가 있음 • 같은 inode에 속한 node들은 자기이전 node보다는 항상 큰 version 번호를 가짐 • version 번호는 32bits임 • 플래시 메모리가 생명을 다하기 전엔 한 inode에 대해서 node는 계속 증가되는 값을 가질 수 있을 것임 • 한 inode에 대해서 4G개의 node를 표현 • 비슷하게 inode번호도 32bits로 저장 • inode 번호는 재사용되지 않음 • JFFS1의 raw node는 보통 inode 메타데이터(uid,gid, mtime,atime등등)뿐만 아니라 속해있는 inode의 이름과 부모 inode의 inode 번호도 포함하고 있음 JFFS : The Journaling Flash File System

11. Log structured • 데이터는 특정위치에 저장되지 않음 • node는 기록이 변하면 Log에 순차적으로 기록됨 JFFS : The Journaling Flash File System

12. 저장 형식 • 각 node는 상당량의 데이터를 가질수도 있음 • 만약 데이터가 유효하다면, 파일내에서의 오프셋을 기록해야함 • 물리적인 node들의 최대크기는 제한적이기에, 큰 파일들은 각 부분부분의 데이터를 가지는 node들이 매우 많을 수 있음 • inode에서 다른 node에 의해 버려진 node는 “dirty space”라고 불리움 • 메타데이터에서도 존재하지 않는 node가 됨 • inode 삭제는 inode 메타데이터에 있는 “deleted “ flag 를 설정함 • 삭제된 inode들끼리 연관되어 관리되며, 이들은 dirth space가 됨 JFFS : The Journaling Flash File System

13. 연산 • 마운트 시점에 전체 장치가 스캔되면서 각 node는 읽기연산이 수행되며, 분석됨 • raw node에 저장된 데이터들은 다시 디렉토리 구조와 물리적 위치의 inode map을 재구성하는데 충분한 정보를 가지고 있음 • 파일 읽기 연산은 연관된 물리적 위치를 이용해 즉시 읽기가 가능함 • 소유자변환이나 권한 변경등 메타데이터의 정보를 변경시키는 것은 로그의 끝에 관련 메타데이터를 새로운 node로 기록함으로 쉽게 해결 • 파일 쓰기도 비슷함. 단지 node가 데이터 관련 node라는 것이 다름 JFFS : The Journaling Flash File System

14. 가베지 컬렉션 • JFFS code가 jffs_raw_inode 구조체를 모두 기록하여 더 이상 기록할 곳이 없으면 “dirty space”를 반환 받으려고 시도함 • Log 내에서 가장 오래된 node는 head 로 알 수 있음 • 새로운 node는 Log 내에 tail 에 추가됨 • 가베지 컬렉션이 한 번도 동작하지 않은 File System에서는 Log의 head 는 플래시의 맨 처음에 있음 • tail 이 플래시의 끝에 위치하면 가베지 컬렉션이 동작하여 빈 공간을 만듬 JFFS : The Journaling Flash File System

15. 가베지 컬렉션 (Con’t) • 가베지 컬렉션은 Kernel Thread에서 미리 빈 공간을 확보하기 위해 동작할 수 있고, User Process에서 쓰기 연산에 의해 동작할 수 있음 • 만약 “dirty space”가 충분하지 않다면 Kernel Thread는 sleep상태로 가고, User Process는 쓰기 연산에서 ENOSPC라는 Error를 발생 시킴 • 가베지 컬렉션 code의 목적은 Log내에 첫번째 블록을 지우는 것임 • Log내에 head에 위치한 node를 검사함 • 만약 node가 dirty space라면 head를 다음 node로 넘김 • 만약 node가 유효한 데이터를 가지고 있다면 이를 Log의 맨 뒤로 복사함 • 가베지 컬렉션 code는 Log의 tail에 새로운 데이터나 메타데이터를 기록함으로 해서 동작함 • Log 뒤에 복사되는 node는 다른 node들과 합병되어 원본 node보다 크게 복사될 수 있음 • 메모리의 효율적인 저장을 위함 JFFS : The Journaling Flash File System

16. 가베지 컬렉션(Con’t) • Dirty space • Dirty space : 더 이상 사용하지 않는 데이터가 저장 된 곳 <초기 플래시 메모리 상태> < File System에서 몇몇의 파일 작업을 거친 후> • Log가 플래시 메모리의 끝에 닿았을 경우 • dirty space의 반환을 요구할 필요가 있음 JFFS : The Journaling Flash File System

17. 가베지 컬렉션 (Con’t) • 시작 부터 끝에 남은 공간까지 아직 남아있는 자료를 복사함 • 시작부터 블록을 소거가 가능 JFFS : The Journaling Flash File System

18. 운영법 • JFFS는 항상 가베지 컬렉션등이 동작하기 위해서 Log내에 head와 tail사이에 가용적인 공간이 필요함 • Log내의 head로 부터 다음 블록을 소거가능하기 위해서 새로운 node를 기록할 공간이 필요함 • 가베지 컬렉션이 동작하기 위한 정확한 여유공간의 계산은 현 알고리즘으로는 명확히 증명이 불가능 • 실험적인 결과가 4개의 플래시 섹터가 가베지 컬렉션에 충분하다는 것을 말해줄 뿐임 JFFS : The Journaling Flash File System