요약: JFFS(Journaling Flash File System)와 YAFFS(Yet Another Flash File System)에 대해 들어보았을테지만, 기반 플래시 디바이스 위에서 동작하는 파일 시스템이 무엇을 의미하는지 알고 있습니까? 이 기사는 리눅스(Linux®)를 위한 플래시 파일 시스템에 대해 소개하고, 닳기 균등화를 통해 반영구적인 기반 디바이스(플래시)를 보호하는 방법을 익히고, 기본적인 설계와 함께 다양한 플래시 파일 시스템을 알아보겠습니다.
원문 게재일: 2008 년 9 월 23 일
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
반도체를 이용한 드라이브(SSD)는 오늘날 일반 컴퓨터 분야에서 열풍이 불고 있지만, 임베디드 시스템에서는 상당히 오래 전부터 반도체를 이용한 드라이브를 저장소로 사용해왔다. PDA, 휴대폰, MP3 플레이어, 디지털 카메라, USB 플래시 드라이브, 심지어 랩톱 컴퓨터에 이르기까지 여러 곳에서 사용되는 플래시 파일 시스템을 찾을 수 있다. 많은 경우에 상용 디바이스를 위한 파일 시스템은 전용이나 독점 형태로 만들어지지만, 이번 기사에서 논하는 동일한 도전에 직면하고 있다.
플래시 기반 파일 시스템 형태는 다양하다. 이 기사에서는 두 가지 읽기 전용 파일 시스템을 살펴보고 오늘날 사용 가능한 다양한 읽기/쓰기 파일 시스템과 동작 원리를 살펴본다. 여기서 우선 플래시 디바이스와 플래시 디바이스가 직면한 도전을 살펴보자.
여러 가지 다양한 기술에 쓰이는 플래시 메모리는 비휘발성 메모리다. 비휘발성 메모리는 전원이 끊겨도 내용을 영구적으로 보관한다는 의미다. 플래시 메모리 역사를 소개하는 훌륭한 자료는 참고자료 절을 참조하자.
기술에 따라 정의되는 플래시 디바이스에서 가장 흔한 두 가지 유형은 NOR와 NAND다. NOR 기반 플래시는 용량을 희생해 읽기 속력을 높인 좀 더 오래된 기술이다. NAND 플래시는 상당히 빠른 쓰기와 삭제 성능과 좀 더 큰 용량을 제공한다. 또한 NAND에는 좀 더 복잡한 I/O 인터페이스가 필요하다.
일반적으로 플래시 메모리는 (특정 파티션을 읽는 동안 다른 파티션은 지우는 등) 여러 연산이 동시에 수행하도록 파티션으로 나뉜다. 파티션은 다시 (일반적으로 64KB나 128KB 크기인) 블록으로 나뉜다. 파티션을 사용하는 펌웨어는 블록을 세그먼트 단위로 접근한다. 예를 들어, 블록 내부에서 메타데이터를 포함하지 않은 512바이트짜리 세그먼트를 사용한다.
플래시 디바이스는 RAM 디스크 같은 여타 저장 디바이스와 비교할 때 디바이스 관리를 요구하는 공통적인 제약이 있다. 플래시 메모리 디바이스에 허용된 유일한 쓰기 연산은 비트를 1에서 0로 바꾸는 행위다. 반대 연산이 필요하면, 블록은 (모든 비트를 0 상태로 리셋하기 위해) 반드시 지워져야 한다. 이는 블록 내 다른 유효한 자료도 영속적인 보관을 위해 다른 곳으로 이동해야 함을 의미한다. NOR 플래시 메모리는 일반적으로 한번에 바이트 하나를 다루도록 프로그램되는 반면에 NAND 플래시는 다중 바이트 버스트(일반적으로 512바이트) 방식으로 프로그램되어야 한다.
블록 삭제 과정은 NOR와 NAND 유형에 따라 다르다. 각각은 플래시 메모리의 전체 블록을 다루는 특수한 삭제 연산이 필요하다. NOR 기술은 삭제 연산을 시작하기 앞서 모든 값을 0으로 정리하는 선행 단계가 필요하다. 삭제는 플래시 디바이스 입장에서 특수한 연산이며, 수행 시간을 요구한다. 삭제는 전자적인 연산이며, 전체 블록에서 각 셀로부터 전자를 빼낸다.
NOR 플래시 디바이스는 일반적으로 삭제 연산에 몇 초가 걸리는 반면에, NAND 디바이스는 몇 밀리초가 걸린다. 플래시 디바이스는 수행 가능한 삭제 연산 횟수가 정해져 있다는 핵심 특성이 있다. NOR 디바이스에서 플래시 메모리에 존재하는 각 블록은 10만 번까지 삭제될 수 있다. NAND 플래시 메모리는 100만 번까지 삭제될 수 있다.
직전 절에서 살펴본 여러 가지 제약 때문에 플래시 디바이스 관리에는 몇 가지 위협적인 도전이 도사리고 있다. 가장 중요한 도전은 가베지 컬렉션, 손상된 블록 관리, 닳기 균등화다.
가베지 컬렉션은 (몇몇 무효한 자료를 포함하고 있는) 무효 블록을 수집하는 과정이다. 수집 기능은 유효한 자료를 새 블록으로 옮긴 다음에 사용 가능하도록 무효 블록을 삭제하는 과정을 밟는다. 이런 과정은 배경 작업이나 파일 시스템 공간이 부족할 때 필요에 따라 수행된다.
시간이 지남에 따라, 플래시 디바이스는 사용 도중에 블록이 손상되며, 심지어 제조사에서 제품이 출시될 때 손상된 블록이 있어서 이 영역을 사용하지 못할 수도 있다. (삭제와 같은) 실패한 플래시 연산이나 ECC(Error Correction Code)로 점검이 가능한 무효한 쓰기 연산을 통해 손상된 블록을 감지할 수 있다.
손상된 블록을 감지하고 나면, 플래시 자체 내부에 존재하는 손상된 블록 테이블에 표식을 달아야 한다. 이런 작업은 디바이스마다 다르지만, 일반적인 자료 블록에서 독립적으로 관리하는 분리된 예약 블록 집합으로 구현할 수 있다. 디바이스 출시 시점이나 시간에 지남에 따라 손상된 블록을 다루는 과정은 손상된 블록 관리라고 부른다. 어떤 경우에는 이런 기능이 내부 마이크로컨트롤러가 제공하는 하드웨어로 구현되어 있으므로 상위 단계 파일 시스템에 비쳐 보인다.
플래시 디바이스는 반영구적인 부품이라는 사실을 상기하자. 각 블록이 망가지기 전까지 삭제 사이클은 유한하다(또한 손상된 블록 관리자가 망가진 블록에 표식을 달아야 한다). 플래시 수명을 최대로 연장하려면, 닳기 균등화 알고리즘을 제공해야 한다. 닳기 균등화는 동적 닳기 균등화와 정적 닳기 균등화라는 두 가지 기술로 나뉜다.
동적 닳기 균등화는 특정 블록에 대한 삭제 사이클에 제한이 있다는 문제점을 해결하기 위해 나왔다. 가용 블록을 임의로 사용하는 대신에, 동적 닳기 균등화 알고리즘은 블록 사용을 균등하게 분포하도록 시도해 각 블록이 똑같은 횟수만큼 쓰이도록 만든다. 정적 닳기 균등화 알고리즘은 좀 더 흥미로운 문제를 해결한다. 삭제 사이클에 최대 횟수가 정해진 이외에 특정 플래시 디바이스는 지우기 사이클 사이에 최대 읽기 사이클 횟수도 정해져 있다. 이는 블록에서 자료가 너무 오래 머무르고 너무 많이 읽힐 경우 자료가 사라져 손상될 수 있음을 의미한다. 정적 닳기 균등화 알고리즘은 주기적으로 안정적인 자료를 새로운 블록에 옮기는 방법으로 이런 문제를 해결한다.
지금까지 플래시 디바이스와 근본적인 도전을 살펴보았다. 이제 이런 조각을 하나로 합쳐 계층화된 아키텍처 일부로 살펴보자(그림 1 참조). 상위에는 가상 파일 시스템(VFS)이 있는데, 좀 더 상위 응용 프로그램에 대한 공통 인터페이스를 나타낸다. VFS 다음에는 플래시 파일 시스템이 따라오며 다음 절에서 다룬다. 그 다음으로 FTL(Flash Translation Layer)이 있는데 주소 변환, 동적 닳기 균등화, 가베지 컬렉션은 물론이고 기반 플래시 디바이스에서 블록 할당을 포함한 전반적인 플래시 디바이스 관리 기능을 제공한다. 몇몇 플래시 디바이스에는 FTL 일부가 하드웨어로 구현되어 있다.
그림 1. 플래시 시스템의 기본 아키텍처
리눅스 커널은 플래시 디바이스를 위한 일반적인 인터페이스인 MTD(Memory Technology Device) 인터페이스를 사용한다. MTD는 플래시 디바이스 버스 폭과 버스 폭을 구현하는 데 필요한 디바이스 번호를 자동으로 감지한다.
여러 가지 플래시 파일 시스템을 리눅스에서 사용할 수 있다. 다음 절은 각각에 대한 설계와 장점을 설명한다.
가장 초기에 등장한 리눅스 플래시 파일 시스템 중 하나가 바로 JFFS다. JFFS는 로그 기반으로 만들어진 파일 시스템으로 NOR 플래시 디바이스를 대상으로 설계되었다. 플래시 디바이스에만 등장하는 다양한 문제점을 해결하기 위한 목적으로 만들어졌지만 다른 문제점을 낳고 말았다.
JFFS는 플래시 디바이스를 블록의 순환 로그로 바라본다. 플래시에 자료를 쓰면, 꼬리에 쓰며, 머리에 있는 블록은 무효한 블록으로 수집된다. 꼬리와 머리 사이에 있는 공간은 자유 공간으로, 이 공간이 줄어들면 가베지 컬렉터를 시동한다. 가베지 컬렉터는 유효한 블록을 로그의 꼬리로 이동하며, 유효하지 않거나 사용되지 않는 블록은 건너뛰며 삭제한다(그림 2 참조). 이런 결과로 인해 파일 시스템은 정적이며 동적인 닳기 균등화를 자동으로 진행한다. 이런 아키텍처에 따라오는 근본적인 문제는 (최적화된 삭제 전략 대신에) 플래시 디바이스를 너무 자주 지우므로 디바이스가 너무 빨리 닳아버린다.
그림 2. 가베지 컬렉션 직전과 직후에 나타나는 순환 로그
JFFS를 마운트할 때, 세부 구조 내역은 메모리에 올라오므로, 마운트 시점에서 느리며 필요 이상으로 더 많은 메모리를 소비한다.
JFFS가 개발된 시절에는 아주 유용했지만, 닳기 균등화 알고리즘은 NOR 플래시 디바이스 수명을 단축하는 경향이 있었다. 이런 결과로 인해 순환 로그를 제거하도록 기반 알고리즘을 다시 설계하게 되었다. JFFS2 알고리즘은 NAND 플래시를 위해 설계되었으며, 압축을 통한 성능 향상을 포함한다.
JFFS2에서 플래시에 있는 각 블록은 독립적으로 다뤄진다. JFFS2는 디바이스 닳기 균등화에 충실하게 블록 목록을 유지한다. clean 목록은 유효한 노드가 가득 찬 디바이스에 있는 블록을 표현한다. dirty 목록은 최소한 사용되지 않는 노드가 하나라도 있는 블록을 포함한다. 마지막으로 free 목록은 삭제되어 사용 가능한 블록을 표현한다.
가베지 컬렉션 알고리즘은 합리적인 방식으로 무효한 블록을 수집할지 현명하게 판단한다. 현재, 일고리즘은 확률적으로 clean이나 dirty 목록에서 선택한다. dirty 목록에서 (유효한 내용을 다른 블록으로 옮기는 방법으로) 무효한 블록을 수집하는 데 선택된 99% 시간을 보내고, clean 목록에서 (단순히 새로운 블록으로 내용을 옮기는 방식으로) 무효한 블록을 수집하는 데 1% 시간을 보낸다. 양쪽 모두 선택된 블록을 삭제하고 free 목록에 넣는다(그림 3 참조). 이는 가베지 컬렉터가 사용되지 않는 블록을 재활용하도록 만들지만 여전히 정적 닳기 균등화를 지원하기 위해 플래시를 헤집고 다니면서 자료를 옮겨야 한다.
그림 3. JFFS2에서 블록 관리와 가베지 컬렉션
YAFFS(Yet Another Flash File System)
YAFFS(Yet Another Flash File System)는 NAND 플래시를 위해 개발된 또 다른 플래시 파일 시스템이다. 초기 버전(YAFFS)은 512바이트 페이지 단위로 플래시 디바이스를 지원했지만, 새로운 버전(YAFFS2)은 좀 더 큰 페이지 단위와 쓰기 제약이 좀 더 커진 새로운 디바이스를 지원한다.
대다수 플래시 시스템에서, 사용되지 않은 블록은 단순히 사용되지 않는다고 표식이 붙지만, YAFFS2는 추가적으로 단조롭게 증가하는 연속적인 숫자로 블록을 표시한다. 마운트 시점에서 파일 시스템을 탐색할 때, 유효한 아이노드를 잽싸게 찾을 수 있다. YAFFS는 또한 플래시 디바이스 블록 구조를 표현하기 위해 체크포인트를 통한 빠른 마운트 기능을 포함해 램에 트리를 유지하며 일반적인 언마운트 과정에서 램 트리 구조를 플래시 디바이스에 저장하는 과정을 거치므로, 마운트 시점에서 읽어 램으로 복구하는 과정이 빠르다(그림 4 참조). 마운트 시점에서 뛰어난 YFFS2 성능은 다른 플래시 파일 시스템과 비교해 훌륭한 장점으로 작용한다.
그림 4. 체크포인트를 통한 YAFFS2 마운트 시점 최적화
몇몇 임베디드 시스템에서는 변경 가능한 파일 시스템을 제공할 필요가 없다. 변경 불가능한 파일 시스템으로 충분하다. 리눅스는 다양한 읽기 전용 파일 시스템을 제공하는데, 가장 유용한 두 가지는 cramfs와 SquashFS다.
cramfs 파일 시스템은 플래시 디바이스 내부에서 사용 가능한 압축된 읽기 전용 리눅스 파일 시스템이다. cramfs는 간단하고 공간 효율적이라는 주요 특징이 있다. 이 파일 시스템은 메모리 크기가 작은 임베디드 디자인에 활용된다.
cramfs 메타데이터는 압축이 되어 있지 않은 반면에, cramfs는 페이지 단위 기반으로 zlib 압축을 사용하므로 임의 접근이 가능하다(페이지는 접근할 때 압축이 해제된다).
mkcramfs 유틸리티와 루프백 디바이스로 cramfs를 사용할 수 있다.
SquashFS는 플래시 디바이스 내부에서 유용하게 사용 가능한 또 다른 압축 읽기 전용 리눅스 파일 시스템이다. SquashFS는 다양한 라이브 CD 리눅스 배포판에서도 찾을 수 있다. 압축을 위해 zlib 지원 이외에도 SquashFS는 압축 수준과 속력을 개선하기 위해 LZMA(Lembel-Ziv-Markov chain Algorithm)를 활용한다.
cramfs와 마찬가지로 표준 리눅스 시스템에서 mksquashfs와 루프백 디바이스로 SquashFS를 사용할 수 있다.
대다수 오픈 소스와 마찬가지로, 소프트웨어는 계속 발전해 나가며, 새로운 플래시 파일 시스템도 개발 중에 있다. 여전히 개발 중인 흥미로운 대안은 LogFS로 몇 가지 아주 기발한 아이디어를 담고 있다. 예를 들어, LogFS는 플래시 디바이스 자체에 트리 구조를 유지하므로 마운트 시간이 ext2와 같은 전통적인 파일 시스템에 근접한다. LogFS는 또한 (B+ 트리 형식으로) 가베지 컬렉션을 위한 트리 탐색 기법을 사용한다. 하지만 LogFS를 특히 흥미롭게 만드는 특성은 뛰어난 확장 가능성과 대용량 플래시 지원이다.
플래시 파일 시스템의 인기가 커져감에 따라, 플래시 기술에 대한 상당히 많은 연구가 진행되고 있음을 확인할 것이다. LogFS가 좋은 예이며, UbiFS와 같은 또 다른 기술도 발전 중이다. 플래시 파일 시스템은 아키텍처 측면에서 흥미로우며, 장래에 계속해서 혁신을 이어나갈 것이다.
교육
- 위키백과에 나온 플래시 메모리 기술과 파일 시스템 목록 개괄을 살펴보자. 여기에는 디스크 기반 파일 시스템, 분산 파일 시스템, (SSD 매체 파일 시스템을 포함해) 특수 목적 파일 시스템이 포함되어 있다.
- NAND vs. NOR flash technology에 대한 내용을 읽어보자.
- 팀이 쓴 "리눅스 파일 시스템 분석"(한국 developerWorks, 2008년 5월)은 VFS와 주요 구조체, 아키텍처를 소개한다. 이 기사는 또한 파일 시스템에 대한 소개 내용과 리눅스가 동시에 상당히 많은 파일 시스템을 지원할 수 있는 방법을 설명한다.
- JFFS and its successor, JFFS2(PDF 파일)를 읽고 플래시 디바이스 관리에 대한 다양한 접근 방법을 살펴보자.
- YAFFS와 그 밖의 인기 있는 플래시 파일 시스템을 비교하자.
- LogFS와 UbiFS는 현재 플래시 파일 시스템이 안고 있는 여러 문제점을 해결하는 새로운 플래시 파일 시스템이다.
- MTD는 플래시 메모리와 같은 메모리 디바이스를 위한 일반적인 하위 시스템이다. MTD는 저 수준 하드웨어 드라이버와 파일 시스템 상위 층 사이에 끼어 있는 일반적인 인터페이스를 제공한다.
- Cramfs와 SquashFS는 리눅스를 위한 읽기 전용 압축 파일 시스템이다. 둘 다 메모리에 제약이 있는 임베디드 시스템을 위해 설계되었지만 SquashFS는 라이브 CD 배포판에도 사용되고 있다. 종종 (특정 파일 시스템을 다른 파일 시스템으로 충첩하는) 파일 시스템을 위한 연합 마운트 기능을 구현한 UnionFS를 라이브 CD에 사용하는 경우도 있다. SquashFS는 LZMA를 사용해 압축 효율과 성능을 높였으며, 패치 집합을 제공한다.
- developerWorks에서 팀이 쓴 모든 ... 분석 기사를 읽어보자.
- developerWorks에서 팀이 쓴 모든 기사를 읽어보자.
- developerWorks 리눅스 영역은 리눅스 개발자를 위한 자료를 제공한다. 가장 인기 있는 기사와 튜토리얼도 찾아보자.
- developerWorks에서 제공하는 모든 리눅스 팁과 리눅스 튜토리얼을 찾아보자.
- developerWorks 기술 행사와 웹 캐스트를 놓치지 말자.
제품 및 기술 얻기
- SEK for Linux 주문: 리눅스용 최신 IBM 평가판 소프트웨어가 들어있는 두 장짜리 DVD를 구하자. DB2®, Lotus®, Rational®, Tivoli®, WebSphere®를 포함한다.
- IBM 평가판 소프트웨어: developerWorks에서 직접 내려받아 다음 번 리눅스 프로젝트에 활용하자.
토론
- 블로그, 포럼, 포드캐스트, 새로운 developerWorks 스페이스에서 제공하는 공동체 토픽을 활용해 developerWorks 공동체에 참여하자.