Nand 플래시의특성과 파일시스템[펌글]
2007.07.24 00:51
아래는 마소지 홈피에서 발췌한 내용임.
=============================================================================================
윈도우 CE를 사용해서 플랫폼을 개발할 경우 시스템 설계 시 고려해야 할 중요한 사항중 하나가 어떠한 저장 매체를 사용할 것인가의 문제이다. 2∼3년 전만 해도 대개 OS 코드는 NOR 플래시에 저장되고 사용자 데이터는 NAND 플래시에 저장하는 것이 일반적이었으나 최근에는 데이터 저장 공간뿐만 아니라 코드 영역까지 NAND 플래시를 사용함으로써 전체 시스템 원가를 절감하고 대용량의 저장 공간을 확보하는 시스템 설계가 점차 확산되는 추세인 것 같다. 그러나 NAND 플래시를 모바일 단말에서 안정적으로 사용하기 위해서는 NAND 플래시의 특성에 적합하게 설계된 파일 시스템이나 FTL(Flash Translation Layer) 같은 시스템 소프트웨어를 필요로 한다.
기본적으로 NAND 플래시는 안정성을 저해하는 몇 가지 결함을 가지고 있다. 예를 들면 양산 시 배드 블럭 발생, 최고 10K번의 지움 횟수 제한, 기록 및 삭제 에러, 읽기 작업 시 1bit 에러 등이 그것이다. 따라서 NAND 플래시를 사용해서 시스템 설계 시 가장 중요한 것은 시스템이 요구하는 코드 및 데이터 저장 공간의 안정성과 성능의 정도를 결정하는 것이다. 그 다음 요구된 사양에 가장 적합한 NAND 플래시 파일 시스템이나 FTL를 선정 또는 개발하는 것이다.
현재 윈도우 CE는 NOR 및 NAND 플래시를 코드 및 데이터 저장 공간으로 사용할 수 있도록 FTL을 기본 제공하고 있다. 점차 개선된 QFE가 제공되고 있긴 하지만 안정성에 문제가 있는 것으로 알려지고 있고, 필자의 경험 또한 다르지 않다. 이러한 문제점을 해결하기 위해 더욱 안정적이고 성능이 강화된 플래시 파일 시스템이나 FTL 솔루션이 써드파티 업체들에 의해 제공되고 있다.
본 글에서는 현재 임베디드 리눅스에 탑재되어 사용되고 있는 YAFFS(Yet Another Flash File System)에 대한 소개와 함께 윈도우 CE에서 기본 제공되거나 기타 써드파티에 의해 제공되는 FTL의 구조에 대해 설명하고 포팅 방법에 대해 기술해보고자 한다. YAFFS는 아직 필자가 포팅을 종료하지 않았으나 또 하나의 솔루션을 소개한다는 차원에서 간단히 언급하겠다.
FTL은 MS 플래시, 삼성 Pocket Store II와 Datalight의 FlashFX Pro에 대해 기본 구조와 포팅법에 대해 설명하고자 한다. 삼성 Pocket Store II, FlashFX Pro의 경우 정보 비공개 유지 협약(NDA) 체결 관계로 인해 깊은 내용을 다룰 수 없음을 미리 밝혀두는 바이다.
NAND 플래시의 특성과 파일 시스템
NAND 플래시 파일 시스템이나 FTL은 NAND 플래시 매체의 특성상 다음의 항목들을 반영해서 개발되어져야 한다. 기존 NAND 플래시 파일 시스템이나 FTL의 선정 시에도 고려해야 함은 물론이다.
배드 블럭 관리
최초 NAND 플래시 포맷 시 배드 블럭(bad block) 여부를 점검해야 한다. 플래시 형태에 따라 bad block mark 정보의 주소가 다르다. 각 블럭의 페이지 0, 1에서 bad block mark 영역을 읽어서 0xff(8bits I/O 경우)가 아니면 배드 블럭으로 판단한다. 지움 작업이나 기록 작업 중에도 정상적으로 작업이 종료되지 않으면 배드 블럭으로 mark하고 더 이상 사용하지 않아야 한다.
기록과 지움 에러
기록과 지움 작업에서 정상적인 작업 종료의 여부는 지움, 기록 커맨드(command) 후의 ‘R/B or IO6, IO0’에 의해 결정된다.
기록 작업의 경우도 <그림 1>과 동일한 과정을 거친다. 다만 ECC (Error Correction Code)를 지원하지 않는 시스템에서는 기록한 데이터를 읽어서 verify 과정을 거쳐야 데이터 무결성을 보장받을 수 있다. 에러가 발생되면 bad block mark를 기록하고 배드 블럭으로 관리한다.
1Bit Error Correction
기록 작업 시 정상적으로 기록이 종료된 경우에도 NAND 플래시 셸(shell)의 전기적 특성으로 인해 read 시 1bit 에러가 발생되는 경우가 있다. 이러한 에러를 보정하기 위해 데이터 기록 시 NAND 플래시의 spare 영역에 ECC 정보를 기록한다. 데이터 읽기 작업에서 실시간으로 계산된 ECC와 spare에 기록된 ECC 정보를 연산해서 1bit 에러를 보정하거나 2bits 에러를 인식할 수 있다. 정상적으로 기록이 된 경우에 2bits 에러는 거의 발생하지 않는 것으로 알려져 있다.
Wear Leveling
NAND 플래시는 10K번을 지움/기록하게 되면 노화 현상에 의해 배드 블럭이 될 가능성이 증가된다. 따라서 전체 NAND 플래시를 균일하게 사용하기 위해 다양한 wear leveling 기법이 사용된다. 플래시 전용 파일 시스템(리눅스용 JFFS 등)과 FTL은 대부분 wear leveling을 지원한다. NAND 플래시를 기존 파일 시스템의 블럭 드라이버에 맵핑(mapping)하는 FTL의 경우에는 physical sector에 맵핑되는 logical sector 번호를 변경함으로써 wear leveling을 구현한다.
NAND 플래시를 끝까지 사용하면 항상 처음 블럭부터 다시 사용하는 방법은 완벽한 wear leveling을 구현할 수는 있으나 블럭 이동과 지움으로 인해 유효한 데이터의 블럭 이동이 빈번해지고 결과적으로 시스템의 성능을 저하시키는 단점이 있다. 따라서 블럭마다 지움 횟수를 관리하면서 현재 유효한 데이터가 가장 적은 블럭을 최우선 지움 대상 블럭으로 선택하는 방법이 wear leveling과 성능을 모두 만족시킬 수 있는 최선의 방법이다.
=============================================================================================
윈도우 CE를 사용해서 플랫폼을 개발할 경우 시스템 설계 시 고려해야 할 중요한 사항중 하나가 어떠한 저장 매체를 사용할 것인가의 문제이다. 2∼3년 전만 해도 대개 OS 코드는 NOR 플래시에 저장되고 사용자 데이터는 NAND 플래시에 저장하는 것이 일반적이었으나 최근에는 데이터 저장 공간뿐만 아니라 코드 영역까지 NAND 플래시를 사용함으로써 전체 시스템 원가를 절감하고 대용량의 저장 공간을 확보하는 시스템 설계가 점차 확산되는 추세인 것 같다. 그러나 NAND 플래시를 모바일 단말에서 안정적으로 사용하기 위해서는 NAND 플래시의 특성에 적합하게 설계된 파일 시스템이나 FTL(Flash Translation Layer) 같은 시스템 소프트웨어를 필요로 한다.
기본적으로 NAND 플래시는 안정성을 저해하는 몇 가지 결함을 가지고 있다. 예를 들면 양산 시 배드 블럭 발생, 최고 10K번의 지움 횟수 제한, 기록 및 삭제 에러, 읽기 작업 시 1bit 에러 등이 그것이다. 따라서 NAND 플래시를 사용해서 시스템 설계 시 가장 중요한 것은 시스템이 요구하는 코드 및 데이터 저장 공간의 안정성과 성능의 정도를 결정하는 것이다. 그 다음 요구된 사양에 가장 적합한 NAND 플래시 파일 시스템이나 FTL를 선정 또는 개발하는 것이다.
현재 윈도우 CE는 NOR 및 NAND 플래시를 코드 및 데이터 저장 공간으로 사용할 수 있도록 FTL을 기본 제공하고 있다. 점차 개선된 QFE가 제공되고 있긴 하지만 안정성에 문제가 있는 것으로 알려지고 있고, 필자의 경험 또한 다르지 않다. 이러한 문제점을 해결하기 위해 더욱 안정적이고 성능이 강화된 플래시 파일 시스템이나 FTL 솔루션이 써드파티 업체들에 의해 제공되고 있다.
본 글에서는 현재 임베디드 리눅스에 탑재되어 사용되고 있는 YAFFS(Yet Another Flash File System)에 대한 소개와 함께 윈도우 CE에서 기본 제공되거나 기타 써드파티에 의해 제공되는 FTL의 구조에 대해 설명하고 포팅 방법에 대해 기술해보고자 한다. YAFFS는 아직 필자가 포팅을 종료하지 않았으나 또 하나의 솔루션을 소개한다는 차원에서 간단히 언급하겠다.
FTL은 MS 플래시, 삼성 Pocket Store II와 Datalight의 FlashFX Pro에 대해 기본 구조와 포팅법에 대해 설명하고자 한다. 삼성 Pocket Store II, FlashFX Pro의 경우 정보 비공개 유지 협약(NDA) 체결 관계로 인해 깊은 내용을 다룰 수 없음을 미리 밝혀두는 바이다.
NAND 플래시의 특성과 파일 시스템
NAND 플래시 파일 시스템이나 FTL은 NAND 플래시 매체의 특성상 다음의 항목들을 반영해서 개발되어져야 한다. 기존 NAND 플래시 파일 시스템이나 FTL의 선정 시에도 고려해야 함은 물론이다.
배드 블럭 관리
최초 NAND 플래시 포맷 시 배드 블럭(bad block) 여부를 점검해야 한다. 플래시 형태에 따라 bad block mark 정보의 주소가 다르다. 각 블럭의 페이지 0, 1에서 bad block mark 영역을 읽어서 0xff(8bits I/O 경우)가 아니면 배드 블럭으로 판단한다. 지움 작업이나 기록 작업 중에도 정상적으로 작업이 종료되지 않으면 배드 블럭으로 mark하고 더 이상 사용하지 않아야 한다.
기록과 지움 에러
기록과 지움 작업에서 정상적인 작업 종료의 여부는 지움, 기록 커맨드(command) 후의 ‘R/B or IO6, IO0’에 의해 결정된다.
기록 작업의 경우도 <그림 1>과 동일한 과정을 거친다. 다만 ECC (Error Correction Code)를 지원하지 않는 시스템에서는 기록한 데이터를 읽어서 verify 과정을 거쳐야 데이터 무결성을 보장받을 수 있다. 에러가 발생되면 bad block mark를 기록하고 배드 블럭으로 관리한다.
1Bit Error Correction
기록 작업 시 정상적으로 기록이 종료된 경우에도 NAND 플래시 셸(shell)의 전기적 특성으로 인해 read 시 1bit 에러가 발생되는 경우가 있다. 이러한 에러를 보정하기 위해 데이터 기록 시 NAND 플래시의 spare 영역에 ECC 정보를 기록한다. 데이터 읽기 작업에서 실시간으로 계산된 ECC와 spare에 기록된 ECC 정보를 연산해서 1bit 에러를 보정하거나 2bits 에러를 인식할 수 있다. 정상적으로 기록이 된 경우에 2bits 에러는 거의 발생하지 않는 것으로 알려져 있다.
Wear Leveling
NAND 플래시는 10K번을 지움/기록하게 되면 노화 현상에 의해 배드 블럭이 될 가능성이 증가된다. 따라서 전체 NAND 플래시를 균일하게 사용하기 위해 다양한 wear leveling 기법이 사용된다. 플래시 전용 파일 시스템(리눅스용 JFFS 등)과 FTL은 대부분 wear leveling을 지원한다. NAND 플래시를 기존 파일 시스템의 블럭 드라이버에 맵핑(mapping)하는 FTL의 경우에는 physical sector에 맵핑되는 logical sector 번호를 변경함으로써 wear leveling을 구현한다.
NAND 플래시를 끝까지 사용하면 항상 처음 블럭부터 다시 사용하는 방법은 완벽한 wear leveling을 구현할 수는 있으나 블럭 이동과 지움으로 인해 유효한 데이터의 블럭 이동이 빈번해지고 결과적으로 시스템의 성능을 저하시키는 단점이 있다. 따라서 블럭마다 지움 횟수를 관리하면서 현재 유효한 데이터가 가장 적은 블럭을 최우선 지움 대상 블럭으로 선택하는 방법이 wear leveling과 성능을 모두 만족시킬 수 있는 최선의 방법이다.
댓글 0
번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
---|---|---|---|---|
30 | sp232 capacitor 오류 | TsKit | 2007.07.15 | 6277 |
29 | atmega spi 2x mode | TsKit | 2007.07.12 | 6390 |
28 | extern array problem | TsKit | 2007.07.10 | 4140 |
27 | bulk-in error | TsKit | 2007.07.08 | 3859 |
26 | 10ms timer 설정(클럭 설정) | TsKit | 2007.06.25 | 4377 |
25 | long 연산 주의할점 | TsKit | 2007.06.24 | 4768 |
24 | long(32bit) 연산 주의할점 II | TsKit | 2007.09.01 | 5469 |
23 | ecc와 속도 | TsKit | 2007.08.20 | 3999 |
22 | const data를 flash area로... | TsKit | 2007.07.31 | 4229 |
21 | device driver단의 read timing | TsKit | 2007.07.29 | 4190 |
20 | nand 파일 시스템과 속도 | TsKit | 2007.07.27 | 4688 |
19 | nand 파일 시스템과 메모리 | TsKit | 2007.07.27 | 5508 |
18 |
jumper input 포트가 필요해서
![]() | TsKit | 2007.07.26 | 3952 |
17 | sd card 초기화 에러시... | TsKit | 2007.07.25 | 5802 |
16 | Timer에게 일을 주자! | TsKit | 2007.07.25 | 3947 |
15 | fat32 포맷할 때는 | TsKit | 2007.07.24 | 4253 |
» | Nand 플래시의특성과 파일시스템[펌글] | TsKit | 2007.07.24 | 10625 |
13 | 아답터 전원 이야기 | TsKit | 2007.09.13 | 4300 |
12 | Font 이야기 | TsKit | 2007.09.04 | 4440 |
11 | avrstudio runtime error 발생 [1] | TsKit | 2008.03.02 | 6126 |