MTD·UBI·UBIFS와 eMMC 파일 시스템을 구분합니다

raw flash와 관리형 저장장치는 출발점이 다릅니다

raw flash의 대표 경로	관리형 저장장치의 대표 경로
파일 → UBIFS → UBI → MTD → raw NAND/NOR	파일 → ext4 등 → block layer → eMMC·SSD 등의 controller
운영체제가 erase block·bad block 등 raw flash 특성을 고려합니다.	내부 controller와 FTL이 flash 물리를 감추고 block I/O를 제공합니다.

UBIFS는 UBI volume 위에서 동작하는 파일 시스템입니다. UBI는 파일 이름·디렉터리를 관리하는 파일 시스템 자체가 아닙니다. JFFS2는 UBI를 필수로 거치지 않고 MTD 위에서 동작합니다. eMMC 안에 NAND가 있다는 이유만으로 /dev/mmcblk 장치를 UBIFS의 일반 대상이라고 보면 안 됩니다. UBIFS와 MTD·UBI의 관계

LEB와 PEB의 크기는 장치와 배치에 따라 달라집니다

PEB는 물리 erase block, LEB는 UBI가 제공하는 논리 erase block입니다. UBI는 헤더와 데이터 offset 등을 고려해 PEB 일부를 관리용으로 사용합니다. 예전 예제의 “PEB 128 KiB, LEB 126 KiB”는 특정 조건의 숫자이지 UBI의 보편적인 상수가 아닙니다.

논리 erase block에서 flash 위치까지

UBIFS의 논리 데이터
파일 시스템이 UBI volume의 LEB 번호와 내부 offset을 사용합니다.
UBI가 현재 대응하는 PEB를 찾습니다.
UBI의 매핑
wear leveling·bad block 처리 등에 따라 물리 배치가 바뀔 수 있습니다.
MTD에 필요한 I/O를 요청합니다.
MTD와 flash driver
장치의 page·erase 단위와 오류 상태를 처리합니다.

화살표는 주소 해석과 I/O 요청의 계층입니다. 파일이 바뀔 때 항상 전체 flash를 순서대로 복사한다는 뜻은 아닙니다.

UBIFS의 superblock·master node 위치에 대한 설명을 UBI 전체의 일반 volume 규칙과 혼동하지 않습니다. 어느 계층의 구조를 설명하는지 이름을 붙여야 합니다. Linux MTD 프로젝트의 UBI 설명

NAND의 불량 블록 마커, BBT, UBI 매핑은 서로 다릅니다

raw NAND에서 출하 시 표시된 불량 블록을 피하는 일과, UBI volume의 데이터를 어느 물리 블록에 둘지 정하는 일은 다릅니다. 아래 구분은 Linux v6.18의 raw-NAND BBT 구현을 기준으로 하며 eMMC 내부 FTL의 구현을 설명하지 않습니다.

정보	역할과 범위
공장 불량 블록 마커	칩이 정한 spare/OOB 영역의 표시는 출하 시 불량 상태를 알려 줍니다. 위치·판정 규칙은 해당 칩 데이터시트와 드라이버를 확인해야 하며, 모든 NAND에 같은 바이트 위치를 적용할 수 없습니다.
Linux BBT	블록 상태를 조회하는 bad block table입니다. RAM의 표와 선택적으로 flash에 보관하는 표를 구분해야 합니다. 이 표의 항목 인코딩은 칩의 마커 형식과 같다는 뜻이 아닙니다.
UBI의 LEB→PEB 매핑	MTD 위에서 논리 eraseblock을 물리 eraseblock에 대응시킵니다. wear leveling과 불량 블록 처리로 배치를 관리하며, 파일 이름과 디렉터리는 그 위의 UBIFS가 맡습니다.

Linux raw-NAND는 flash BBT를 쓰지 않는 경로에서 장치의 마커를 스캔해 RAM BBT를 만듭니다. flash BBT를 사용하는 경우에도 읽은 정보를 RAM에 구성합니다. 미러와 버전 관리를 선택하면 두 표의 버전을 비교하고, 버전 관리가 없으면 양쪽 불량 정보를 합치는 경로가 있습니다. 표가 없을 때의 생성과 flash 기록은 각각 NAND_BBT_CREATE, NAND_BBT_WRITE 등의 설정에 달려 있으므로 모든 장치가 부팅 때 BBT를 새로 기록한다고 해석하면 안 됩니다. v6.18 nand_scan_bbt·check_create 구현

마커를 담은 불량 블록을 지우면 제조 시의 정보를 잃을 수 있습니다. BBT가 있다는 이유로 마커를 지우거나 임의로 다시 쓰면 안 됩니다. BBT 저장 위치와 OOB/ECC 배치도 장치 설정에 따라 달라지며, 이 설명은 초기화·복구 명령이나 특정 칩의 첫 블록 보장을 제시하지 않습니다. MTD NAND의 bad block table 설명

UBI의 volume 관리와 wear leveling은 이 하위 블록 상태 관리와 다른 층입니다. BBT를 LEB→PEB 주소 변환표나 파일 시스템의 목록으로 보면 안 됩니다. UBIFS와 UBI의 계층 · 사이트의 MTD NAND 상세 문서

파일 시스템 이미지와 UBI 이미지는 다릅니다

산출물	담는 것	맞춰야 하는 정보
UBIFS image	UBIFS 파일 시스템 내용	minimum I/O, LEB 크기, 최대 LEB 수 등 대상 설정
UBI image	UBI volume 배치와 각 volume의 내용	PEB 크기·헤더 offset·volume 구성 등
ext4 image	block 장치 위의 ext4 파일 시스템	대상 block 공간·feature 지원·마운트 구성

확장자만 보고 기록 방법을 선택하지 않습니다. rootfs.ubifs를 raw flash 전체용 이미지처럼 취급하거나 UBI 헤더가 포함된 이미지를 일반 파일 시스템 이미지처럼 마운트하면 계층이 맞지 않습니다. 이미 사용 중인 volume의 갱신과 flash 초기화도 다른 작업입니다.

지우기 전에 현재 geometry부터 읽습니다

cat /proc/mtd
cat /sys/class/mtd/mtd0/erasesize
cat /sys/class/mtd/mtd0/writesize
ubinfo -a

관찰용 명령 예입니다. mtd0이라는 장치가 실제로 존재하는지 먼저 확인해야 하며 ubinfo는 도구 설치와 UBI 장치 상태에 따라 결과가 달라집니다. 여기서는 erase·format·raw write 명령을 예제로 실행하지 않습니다. 장치 정보와 이미지 생성 설정을 맞추는 것이 먼저입니다.

증상	나누어 볼 원인
attach 실패	잘못된 flash 영역, 헤더·geometry 불일치, 손상, 지원 설정 등을 확인합니다.
UBI는 보이지만 mount 실패	volume 종류와 내용, UBIFS 형식·기능, mount 대상 이름을 확인합니다.
전원 차단 뒤 문제	write 완료·commit·업데이트 절차와 실제 오류 로그를 봅니다. “journal이 있으니 모든 작업이 보존된다”고 가정하지 않습니다.

관리형 NAND의 FTL, GC와 마모 분산

관리형 eMMC·SSD의 host LBA는 NAND의 물리 page 번호가 아닙니다. 내부 FTL이 주소를 대응시키기 때문에 같은 LBA를 다시 써도 다른 빈 page로 이동할 수 있습니다. 예를 들어 LBA 10을 P0에서 P5로 갱신하면 이후 읽기는 새 매핑을 따라갑니다. 이전 P0는 최신 데이터가 아니지만 즉시 지워진 빈 page가 되지는 않습니다. 실제 장치의 mapping metadata 갱신·전원 장애 복구 절차는 이 단순 예보다 복잡합니다.

NAND의 program 단위와 erase block 단위가 다르므로 임의의 바이트를 RAM처럼 덮어쓰는 모델은 맞지 않습니다. 정확한 page 크기·spare 영역·허용 program 규칙은 칩별입니다. LBA 크기, 파일시스템 block 크기와 NAND page 크기를 같은 숫자로 놓지 않습니다.

Page-level mapping은 작은 갱신의 위치를 유연하게 정하지만 세밀한 매핑 표가 필요합니다. Block-level mapping은 표를 줄이는 대신 작은 갱신의 이동 비용이 커질 수 있습니다. Hybrid 방식은 data block과 log/update block을 나누며, 흩어진 유효 데이터를 합치는 merge 비용이 생깁니다. 2009년 DFTL은 모든 page 매핑을 RAM에 상주시킨다는 가정 대신 flash의 translation page와 필요한 매핑의 RAM cache를 사용하는 연구 사례입니다. 모든 SSD가 DFTL을 구현한다는 뜻은 아닙니다.

GC는 victim block 선정 → 유효 page 이동 → block erase의 세 작업을 구분해야 합니다. 네 page 중 세 개가 유효한 block을 회수한다면 세 page를 다른 빈 공간으로 옮긴 뒤 네 page를 지웁니다. metadata 등 부가 비용을 제외한 이 예에서 순증하는 빈 공간은 한 page입니다. Host가 쓴 데이터보다 내부 program 양이 커지는 write amplification을 설명하는 이유이지 특정 제품의 실측 수치가 아닙니다.

Victim 정책에도 차이가 있습니다. Random·round-robin·greedy·cost-benefit은 서로 다른 기준을 사용합니다. 유효 page가 적은 block은 즉시 복사 비용을 줄일 수 있지만, 수명·데이터 갱신 빈도·유휴 시간·여유 공간까지 함께 고려하면 같은 선택이 항상 최선은 아닙니다. 강의의 한 정책이나 과거 실험의 우선순위를 모든 controller의 규칙으로 옮기지 않습니다.

파일 삭제로 파일시스템이 빈 공간을 알게 되는 시점과 장치가 그 LBA를 더는 보존할 필요 없다고 아는 시점은 다릅니다. Discard·TRIM·UNMAP 같은 경로는 관련 계층이 지원하고 전달할 때 사용하지 않는 범위를 알립니다. 이는 즉시 물리 erase 완료, 안전 삭제, 일정한 성능 향상의 보장이 아닙니다. fstrim의 보고량 역시 실제 새로 지워진 물리 바이트가 아니라 장치에 전달한 잠재적 discard 범위로 읽어야 합니다. 여기서는 trim이나 erase 명령을 실행하지 않았습니다.

GC의 주목적이 공간 회수라면 wear leveling은 일부 block에 P/E 사용이 몰리지 않게 하는 일입니다. Dynamic 방식은 새 쓰기에 사용할 free block의 마모 정도를 고려합니다. Static 방식은 오래 바뀌지 않는 cold data가 있는 사용 중 block도 이동 대상으로 삼을 수 있어, 추가 내부 쓰기와 성능 비용이 발생합니다. 분산 대상·주기·기준은 제품 구현에 따라 다르며, 강의의 과거 P/E 횟수를 현재 NAND의 보증 수명으로 쓰지 않습니다.

F2FS의 section·segment cleaning은 파일시스템의 논리 block 위에서 일어나고, FTL의 GC는 장치 내부 erase block을 다룹니다. F2FS의 NAT는 node block 위치를 관리해 갱신 전파를 줄이는 구조이지 장치의 LBA→물리 page 매핑 표가 아닙니다. Hot/cold log 분리와 정렬은 비용을 줄이려는 설계지만 불투명한 FTL의 물리 배치와 반드시 일치한다는 보장은 없습니다. Raw NAND의 UBI LEB→PEB 경로는 앞 절처럼 별도로 읽습니다.

기준: Ming-Chang Yang의 2020 CSCI5550 Flash Memory 강의 12–14·19–35·45–49쪽, KIOXIA wear leveling 해설, Linux F2FS 문서, fstrim(8). 설명과 계산 예시는 새로 작성했으며 원 강의 도표를 복제하거나 장치 성능·내구성을 측정하지 않았습니다.

English summary. FTL address mapping, garbage collection and wear leveling solve different problems. Valid-page relocation adds writes; discard is not a physical erase receipt. File-system cleaning and NAT remain distinct from device-internal mappings and erase blocks.