JFFS : The Journaling Flash File System

ISLab ICE HUFSISLab ICE HUFS

JFFS : The Journaling Flash File JFFS : The Journaling Flash File SystemSystem

David WoodhouseRed Hat, Inc.

2006.01박성환 ([email protected])


JFFS : The Journaling Flash File System 2

목 차목 차

1. 서론1. 플래시 메모리2. FTL (Flash Translation Layer)

2. JFFS Version 11. 저장 형식 (Storage Format)2. 연산 (Operation)3. 가베지 컬렉션 (Garbage Collection)4. 운영법 (Housekeeping)



서 론서 론

• JFFS (Journaling Flash File System)– Log-structured File System on Flash Devices in

Embedded System

• JFFS2– 압축과 효율적인 Garbage Collection 을 사용



플래시 메모리플래시 메모리

• NOR 와 NAND type– NOR : 직접 접근 가능– NAND : 블록과 섹터로 접근 가능

• 블록단위로 소거 (Reset) 가 가능

• 블록은 약 100,000 번 소거시 생명주기를 다함– 때문에 소거 횟수 평준화 (Wear Leveling) 가 필요함

• 논문에서 정의한 단어– Page : 512 bytes– Out of band : 16 bytes

• 메타데이터나 에러 정정 코드등을 저장



FTL (Flash Translation Layers)FTL (Flash Translation Layers)

• 데이터의 수정은 해당블록의 소거연산이 선행됨

• 때문에 FTL 이 중간에서 효율적인 연산으로 변환하는 역할을 함

• FTL 에서 소거 횟수 평준화도 제공 가능

• 이런 FTL 이 사실상 Journaling File System 의 모습이 됨


JFFS Version 1JFFS Version 1

JFFS 는 Embedded 와 베터리 전력을 사용하는 System 에서 신뢰적인 연산과

예기치 못한 System ShutDown 을 처리하기 위해 디자인 됨



JFFS JFFS 구조구조

App 1 App 2 App 3

Virtual File System (VFS)

JFFS hpfsFATExt2...

Buffer Cache

Disk DriverFlash Driver

Disk DeviceFlash Device

User Space

Kernel Space

Hardware

• JFFS 는 Buffer Cache 를 사용하지 않음



저장 형식저장 형식

• Original JFFS 는 순수한 LFS(Log-Structured File System) 이였음

• 데이터나 메타데이터를 가지는 Node 는 순차적으로 저장

• JFFS1 에서 Log 에는 한가지 타입의 Node 만 존재– struct jffs_raw_inode– 각 node 는 단 하나의 inode 에만 연관됨

• Header– inode 들의 번호를 가지고 있음– inode 를 위한 현재 File System 의 메타데이터– 데이터의 총크기의 변수



jffs_raw_inodejffs_raw_inode



저장 형식저장 형식 (Con’t)(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 번호도 포함하고 있음



Log structuredLog structured

• 데이터는 특정위치에 저장되지 않음• node 는 기록이 변하면 Log 에 순차적으로 기록됨

version : 1offset : 0len : 200

data : AAA...

version : 2offset : 200

len : 200data : BBB..

version : 3offset : 175

len : 50data : CCC..

write 200 bytes 'A' at offset zero in file

write 200 bytes 'B' at offset 200 in

file

write 50 bytes 'C' at offset 175

0- 200 : v1

0- 200 : v1

200- 400 : v2

0- 175 : v1

175- 225 : v3

225- 400 : v2

list state

node version 1 :200 bytes @0

node version 2 : 200 bytes @ 200

node version 3 : 50 bytes @ 175



저장 형식저장 형식

• 각 node 는 상당량의 데이터를 가질수도 있음

• 만약 데이터가 유효하다면 , 파일내에서의 오프셋을 기록해야함

• 물리적인 node 들의 최대크기는 제한적이기에 , 큰 파일들은 각 부분부분의 데이터를 가지는 node 들이 매우 많을 수 있음

• inode 에서 다른 node 에 의해 버려진 node 는 “ dirty space”라고 불리움– 메타데이터에서도 존재하지 않는 node 가 됨

• inode 삭제는 inode 메타데이터에 있는 “deleted “ flag 를 설정함– 삭제된 inode 들끼리 연관되어 관리되며 , 이들은 dirth space 가 됨



연산연산

• 마운트 시점에 전체 장치가 스캔되면서 각 node 는 읽기연산이 수행되며 , 분석됨

• raw node 에 저장된 데이터들은 다시 디렉토리 구조와 물리적 위치의 inode map 을 재구성하는데 충분한 정보를 가지고 있음

• 파일 읽기 연산은 연관된 물리적 위치를 이용해 즉시 읽기가 가능함

• 소유자변환이나 권한 변경등 메타데이터의 정보를 변경시키는 것은 로그의 끝에 관련 메타데이터를 새로운 node 로 기록함으로 쉽게 해결– 파일 쓰기도 비슷함 . 단지 node 가 데이터 관련 node 라는 것이 다름



가베지 컬렉션가베지 컬렉션

• JFFS code 가 jffs_raw_inode 구조체를 모두 기록하여 더 이상 기록할 곳이 없으면 “ dirty space” 를 반환 받으려고 시도함

• Log 내에서 가장 오래된 node 는 head 로 알 수 있음

• 새로운 node 는 Log 내에 tail 에 추가됨

• 가베지 컬렉션이 한 번도 동작하지 않은 File System 에서는 Log의 head 는 플래시의 맨 처음에 있음

• tail 이 플래시의 끝에 위치하면 가베지 컬렉션이 동작하여 빈 공간을 만듬



가베지 컬렉션 가베지 컬렉션 (Con’t)(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 보다 크게 복사될 수 있음– 메모리의 효율적인 저장을 위함



가베지 컬렉션가베지 컬렉션 (Con’t)(Con’t)

• Dirty space– Dirty space : 더 이상 사용하지 않는 데이터가 저장 된 곳

< 초기 플래시 메모리 상태>

< File System 에서 몇몇의 파일 작업을 거친 후>

• Log 가 플래시 메모리의 끝에 닿았을 경우– dirty space 의 반환을 요구할 필요가 있음



가베지 컬렉션 가베지 컬렉션 (Con’t)(Con’t)

• 시작 부터 끝에 남은 공간까지 아직 남아있는 자료를 복사함

• 시작부터 블록을 소거가 가능



운영법운영법

• JFFS 는 항상 가베지 컬렉션등이 동작하기 위해서 Log내에 head 와 tail 사이에 가용적인 공간이 필요함– Log 내의 head 로 부터 다음 블록을 소거가능하기 위해서

새로운 node 를 기록할 공간이 필요함

• 가베지 컬렉션이 동작하기 위한 정확한 여유공간의 계산은 현 알고리즘으로는 명확히 증명이 불가능

• 실험적인 결과가 4 개의 플래시 섹터가 가베지 컬렉션에 충분하다는 것을 말해줄 뿐임

Documents

JFFS : The Journaling Flash File System