YAFFS

OS =안드로이드, 파이어폭스 OS, 리눅스, Windows CE, pSOS, RTEMS, eCos, ThreadX, LCOS **YAFFS**(**Yet Another Flash File System**)는 찰스 매닝이 Aleph One사를 위해 설계하고 작성한 파일 시스템이다. YAFFS1은 이 파일 시스템의 첫 번째 버전으로, 당시의 512 바이트 페이지 크기(+ 16 바이트 여유(OOB; Out-Of-Band) 영역)를 가진 NAND 칩을 위해 설계되었다. 작업은 2002년에 시작되어 그해 말에 처음 출시되었다. 초기 작업은 Toby Churchill Ltd와 Brightstar Engineering의 후원을 받았다. 이러한 구형 칩은 일반적으로 페이지당 2~3회 쓰기 주기를 허용한다.Erasing a flash erase block sets all of its bits to 1s, and writing a write block (smaller than an erase block, but possibly bigger than a filesystem block) sets selected bits to 0s. One or two further writes to the block could be sustained if the bits being written to 0 were previously 1s in the write block. Writing a 0 to a bit which was already 0 risked making the 0 "stick", i.e. multiple erases could be needed to return the bit to a 1. Needless to say, this multiple-write practice was not generally tested and guaranteed by flash vendors, and cannot work at all on non-SLC flash technologies. YAFFS는 이를 활용하여 특정 예비 영역 바이트에 써서 더티 페이지를 표시한다. 최신 NAND 플래시 칩은 페이지 크기가 더 커졌는데, 처음에는 2K 페이지(+ 64 바이트 OOB), 나중에는 4K 페이지가 되었으며, 더 엄격한 쓰기 요구 사항이 적용되었다. 소거 블록(128킬로바이트) 내의 각 페이지는 순차적으로 기록되어야 하며, 각 페이지는 한 번만 기록되어야 한다. "한 번 쓰기 규칙"("write once property")을 강제하는 스토리지 시스템을 설계하는 것은 몇 가지 장점이 있다. Jack B. Dennis; Guang R. Gao; and Vivek Sarkar. "Collaborative Research: Programming Models and Storage System for High Performance Computation with Many-Core Processors". p. 4 YAFFS2는 이러한 최신 칩들을 수용하기 위해 설계되었다. 이는 YAFFS1 소스 코드를 기반으로 하며, 주요 차이점은 내부 구조가 512바이트 크기로 고정되어 있지 않고, 각 기록된 페이지에 블록 시퀀스 번호가 부여된다는 점이다. 이런 방식으로 이전 페이지는 "한 번 쓰기" 규칙을 위반하지 않고 논리적으로 덮어쓸 수 있다. 2003년 말에 출시되었다. YAFFS는 데이터 무결성을 최우선으로 하는 견고한 로그 구조화 파일 시스템이다. YAFFS의 보조 목표는 고성능이다. YAFFS는 일반적으로 대부분의 대안보다 뛰어난 성능을 보인다.url=http://elinux.org/Flash_Filesystem_Benchmarks_3.1 또한 이식성을 고려하여 설계되었으며 리눅스, WinCE, pSOS, RTEMS, eCos, ThreadX 및 다양한 특수 목적 운영 체제에서 사용되었다. 'YAFFS/Direct' 변형은 운영 체제가 없거나 임베디드 운영 체제 또는 부트로더가 있는 상황에서 사용된다. 이 변형은 동일한 코어 파일 시스템을 가지고 있지만 상위 및 하위 수준 코드와 NAND 플래시 하드웨어 모두에 대한 인터페이스가 더 간단하다. YAFFS 코드베이스는 GPL과 Aleph One에서 제공하는 제품별 라이선스 모두로 라이선스가 부여된다. YAFFS는 높은 수준에서 파티션별로 잠겨 있어 한 번에 하나의 스레드만 쓸 수 있다.website=yaffs.net
# YAFFS1
YAFFS 파일 시스템을 초기화하는 특별한 절차는 플래시 메모리를 단순히 지우는 것 외에는 없다. 불량 블록이 발생하면 YAFFS는 스마트 미디어 방식에 따라 블록의 여유 영역에서 다섯 번째 바이트를 표시한다. 이렇게 표시된 블록은 그 이후로 할당되지 않은 상태로 유지된다. 파일 데이터를 쓰기 위해 YAFFS는 처음에 파일 메타데이터(예: 타임스탬프, 이름, 경로 등)를 설명하는 전체 페이지(YAFFS 용어로는 청크)를 쓴다. 새 파일에는 고유한 개체 ID 번호가 할당되며, 파일 내의 모든 데이터 청크에는 여유 영역 내에 이 고유한 개체 ID가 포함된다. YAFFS는 이러한 청크의 물리적 위치에 대한 RAM의 트리 구조를 유지 관리한다. 청크가 더 이상 유효하지 않으면(파일이 삭제되거나 파일의 일부가 덮어쓰여진 경우) YAFFS는 청크의 여유 영역에 있는 특정 바이트를 '더티'로 표시한다. 전체 블록(32페이지)이 더티로 표시되면 YAFFS는 블록을 지우고 공간을 회수할 수 있다. 파일 시스템의 여유 공간이 부족하면 YAFFS는 유효한 페이지 그룹을 새 블록으로 통합한다. 그런 다음 YAFFS는 원래 블록 내의 더티 페이지가 사용하던 공간을 회수한다. YAFFS 시스템이 마운트할 때 NAND 플래시 장치는 여유 영역을 스캔하여 유효한 데이터를 확인하기 위해 각 블록을 방문해야 한다. 이 정보를 사용하여 메모리 상주 트리 데이터 구조를 재구성한다.
# YAFFS2
YAFFS2는 YAFFS1과 개념이 유사하며 많은 코드를 공유한다. YAFFS2 코드베이스는 하위 호환성을 통해 YAFFS1 데이터 형식을 지원한다. 주요 차이점은 YAFFS2가 최신 NAND 플래시의 "한 번 쓰기" 요구 사항을 충족하기 위해 상당한 노력을 기울여야 한다는 점이다.url=http://www.yaffs.net/yaffs-2-specification-and-development-notes YAFFS2는 새로 쓰여진 모든 블록에 단조 증가하는 시퀀스 번호를 표시한다. 청크의 시퀀스는 블록 시퀀스 번호와 블록 내 청크 오프셋으로부터 추론할 수 있다. 따라서 YAFFS2가 플래시를 스캔하여 동일한 ObjectIDs 및 ChunkNumbers를 가진 여러 청크를 감지할 때, 가장 큰 시퀀스 번호를 취하여 사용할 청크를 선택할 수 있다. 효율성을 위해 YAFFS2는 축소 헤더(shrink header) 개념도 도입한다. 예를 들어, 파일 크기가 더 작게 조정될 때 YAFFS1은 영향을 받는 모든 청크를 더티로 표시하지만 YAFFS2는 "한 번 쓰기" 규칙 때문에 그렇게 할 수 없다. 대신 YAFFS2는 특정 수의 페이지가 그 시점 이전에 유효하지 않음을 나타내는 "축소 헤더"를 쓴다. 이를 통해 YAFFS2는 시스템이 재부팅될 때 파일 시스템의 최종 상태를 재구성할 수 있다. YAFFS2는 NAND 플래시에 대한 보다 추상적인 정의를 사용하여 다양한 지오메트리, 불량 블록 처리 규칙 등을 가진 더 넓은 범위의 플래시 부품과 함께 사용할 수 있도록 한다. YAFFS2는 나중에 체크포인팅 지원을 추가했는데, 이는 일반적인 마운트 스캔을 우회하여 매우 빠른 마운트 시간을 가능하게 한다. 성능은 달라질 수 있지만, 2 GB의 경우 3초의 마운트 시간이 보고된 바 있다.