임베디드 스터디 - 플래시 메모리 관리

NAND 플래시 마운팅

• NAND의 특징은 다음과 같다.
  • 블록 단위로 데이터 소거, 페이지 단위로 읽기/쓰기 수행
  • Bad Block이 발생, 소거 횟수에 제한이 있음
• Linux의 파일시스템(/ext4 등)은 NAND Flash의 Bad Block을 판단해서 마운팅되지 않음
  • Bad Block에 파일시스템 마운팅 : 데이터 손상
  • 같은 블록만 반복 소거 : 수명 단축
• Linux의 MTD는 이러한 Flash 마운팅 문제를 해결하기 위한 서브시스템임

MTD (Memory Technology Device)

• Flash 메모리를 관리하는 Linux 서브시스템
  • Bad Block 검사
  • Flash 하드웨어 추상화
• MTD의 상위 계층으로 JFFS2/UBIFS 라는 파일 시스템이 올라감

Wear Leveling

• 각 블록의 소거 횟수를 고르게 분산하여 Flash의 수명을 연장시킴
• Wear Leveling을 구현하는 방법은 두 가지가 있음
  • Dynamic WL : 쓰기가 발생하는 블록들 사이에서만 고르게 WL을 수행
  • Static WL : 모든 블록에 대해 고르게 WL을 수행

구분	Dynamic WL	Static WL
대상	쓰기 중인 블록만	cold data 포함 전체
효과	기본적인 수명 분산	더 균일한 수명 분산
오버헤드	낮음	높음 (데이터 이동 발생)

Flash 메모리 최적화 파일시스템

• /ext4는 파일시스템에서 파일을 수정할 때 해당 메모리에 데이터를 덮어씌움
• JFFS2/UBIFS는 절대 같은 위치에 데이터를 덮어씌우지 않음
  • 이러한 동작 방식을 로그 구조(Log-Structured)이라고 함

    파일 수정 시
    → 기존 블록은 "무효(obsolete)" 표시만 함
    → 새 데이터는 항상 새로운 빈 공간에 씀
    → 나중에 무효 블록들을 모아서 한꺼번에 소거 (GC, Garbage Collection)
    

JFFS2 (Journalling Flash File System version 2)

• MTD를 직접 사용하는 파일시스템
  • Flash 전체를 스캔해서 유효 블록을 체크
• 파일시스템이 직접 Wear Leveling을 수행함
  • 로그 구조 자체적인 특성으로 인해 간접적으로 WL을 수행함
  • 그렇다고 로그 구조가 Static WL인 것은 아님
• 마운팅 시간과 Flash 메모리 크기가 비례한다.
  • 대용량 Flash에는 적합하지 않은 파일시스템

UBIFS (UBI File System)

• MTD와 UBIFS 사이에 UBI(Unsorted Block Images)라는 서브시스템을 두는 파일시스템
  • UBI는 물리적 Flash 블록을 논리 블록(LEB, Logical Erase Block)으로 매핑하여 테이블을 관리함
  • UBIFS는 UBI의 논리 블록 기반의 볼륨(Volume)에 파일시스템 마운팅

UBIFS
  파일시스템 A → UBI 볼륨 A에 마운트
  파일시스템 B → UBI 볼륨 B에 마운트
        ↓
UBI
  볼륨 A, B의 논리 블록 ↔ 물리 블록 동적 매핑
  Wear Leveling 수행
        ↓
MTD
  물리 블록 1~10 Bad Block 감지
  UBI에 Bad Block 정보 제공
        ↓
NAND Flash 물리 블록 1~10

----------------------------------------------

볼륨 A (커널 이미지)
  └─ LEB 0, LEB 1, LEB 2  ← 볼륨 안의 논리 블록들

볼륨 B (rootfs)
  └─ LEB 0, LEB 1, LEB 2, LEB 3, LEB 4

UBI 매핑 테이블
  볼륨A-LEB0 → 물리블록 3
  볼륨A-LEB1 → 물리블록 7
  볼륨A-LEB2 → 물리블록 1
  볼륨B-LEB0 → 물리블록 5
  ...