HDD의 경우, disk에 '섹터 n에 데이타를 기록해' 라고 하면,
그냥 기록됩니다.
그러나 플래시메모리의 경우는 좀 다릅니다.
무언가를 기록하기 전에 해당 block에 erase되어 있어야 합니다.
근데, 여기서 문제가 또 발생합니다.
read/write는 block단위로 가능한 반면, erase는 page단위로밖에 할 수 없습니다.
한 page는 다수(이게 보통 32개인가요?)의 block으로 되어 있죠.
이러다보니, 가령, 이런 경우가 발생합니다.
107번 block에 뭔가를 write하고 싶다면,
107번을 제외한 96~127번 사이의 유효한 block을 다른 빈 block을 찾아서
이동시킨 후, 96~127번 block (3번째 page가 되겠죠)를 erase하고
107번에 write를 해야 합니다. 엄청 번거롭죠.
(도대체 이딴 방식의 플래시 메모리가 왜 발명된 건지....)
어쨋건, 여기서 문제가 생깁니다.
HDD의 경우, sector i/o에 있어서의 원자성(이걸 원자성이라고 해야 하나요?)은
유지가 되는 반면, flash memory에서는 그게 유지가 안됩니다. 위에서 설명한 erase하는 과정에서
시스템이 꺼지게 되면, flash memory 자체가 엉망이 되어 버리기 때문이죠.
그래서, 이런 것을 안정적으로 유지하기 위해서
몇가지 테크닉을 사용합니다. i/o transaction을 logging하는 방식으로 구현한다던가,
journal이라는 여분공간을 운영해서 한다던가....
참.
그리고, 한가지 더 있습니다.
flash memory는 수명이 있어서, 이 수명이 넘어가면 해당 page가 bad block으로 갈 확률이 높아지죠.
그래서, 각 page에 erasing count를 세서, 특정 page가 집중적으로 사용되지 않도록
구현될 필요가 있습니다. 즉, block remapping이 필요하다는 거죠.
상위 layer에서 'n번 page에 write해'라고 해도, 사실은 이제 m번 page에 mapping되도록 하는 겁니다.
뭐... 이것을 웨어레벨링이라고도 하는 것 같고요. 보통, FTL 이라고 하면, 이걸 하는 layer를 말할 겁니다.
어쨋건, 그래서 그렇습니다.
플래시메모리에서 ext3같은 block device 기반의 파일시스템을 사용하려면, FTL 역할을 해주는 놈이 있어야 할 거고, 아니라면, jffs2나 yaffs같은 플래시메모리기반의 파일시스템이 필요한 겁니다.
쉽게 말하자면 모든 문제의 근본은 플래시는 Overwrite가 안되기 때문입니다.
아! 좀더 정확히는 NAND Flash는 Overwirte가 안되기 때문입니다.
그래서 지우고 다시 써야 하는데,
또 웃긴것이 NAND Flash는 지우는 단위가 읽고, 쓰기하는 단위보다 약 64배 정도 큽니다.
즉, 한 데이터를 Overwrite하기 위해서는 전혀 상관없는 64개의 영역이 지워졌다가 다시 써져야 합니다.
이거 엄청난 낭비죠.
게다가 지우고 쓰고 하는 횟수도 제한되어 있습니다. 대략 10만번 정도죠.
어느 한 데이터에 계속해서 Update가 발생하면 계속 지웠다/썼다를 반복해야 하는데, 이러면 전혀 상관없는
다른 데이터들까지 사용하지 못하는 사태가 발생합니다.
그래서 Overwrite를 안하고 Update되는 정보를 다른쪽에 쓰고 매핑 테이블 같은걸 만들어서 위치를 알려주는 계층이 필요하죠.
이 계층을 FTL(Flash Translation Layer 스펠링은 맞는지 모릅니다..^^)라고 합니다.
FTL에 대한 여러가지 구현 방법이 있는데 대부분 어떤 식으로든 log를 기록합니다. 자세한건 논문 수준의 내용이 필요합니다.^^
더불어 NAND Flash는 한 번에 쓸 수 있는 데이터 크기가 2Kbyte 짜리인게 대세인 반면 HDD의 sector는 512byte기 때문에 인터페이스 호환을 위해서 FTL에서 이런걸 버퍼링해서 2Kbyte로 만들어주고 어쩌구 하는 작업도 필요합니다.
버퍼링 도중 갑자기 전원이 나가면 또 문제가 되기 때문에 복구해주는 작업도 필요하고...
그래서 NAND flash 파일 시스템은 저널링으로 구현됩니다. FTL의 구현 자체가 기본적으로 저널링 파일 시스템의 원리를 따르고 있을 뿐더러 저널링으로 구현하지 않으면 NAND Flash를 제대로 사용할 수 없기 때문입니다.
----------------------
얇은 사 하이얀 고깔은 고이 접어서 나빌레라
journaling 파일시스템은 예기치 않은 power fail 때 파일시스템이 망가지는 것을 방지해줍니다.
파일 단위로는 어떤 것도 보장하지 않습니다. 지워질 수도 있고, 예전 내용이 되살아날 수도 있고...
wear leveling 은 윗분들이 말씀하신대로 각 erase block 들의 erase 횟수가 같아지도록해서
결과적으로 NOR/NAND 플래시의 수명을 연장시키기 위해 필요합니다.
wear leveling 을 FTL 수준에서 구현하는 것은 쉽지만,
journaling/log 를 FTL 수준에서 구현하는 것은 불가능에 가깝습니다.
그 유명한 ext3 에서 사용하는 jbd 조차도 수많은 함수를 export 해서 파일시스템이 그걸 사용해야만 하는 구조입니다.
파일 시스템수준에서 저 둘을 제대로 구현한 것은 아직 없습니다.
JFFS2 는 log 기반이며, wear leveling 은 random 을 사용하는 방법으로 수학적인 균일분포를 주장하고 있습니다.
LogFS 가 journaling 을 구현했다고는하지만, 논문용 파일시스템수준에서 그치고있기 때문에
도저히 현장에서 써먹을만한 정도의 성능이 나오지 않습니다. CPU 도 겁나게 쳐먹고.
FTL 까지 포함해보자면 (오픈소스에서는 사실 선택의 여지도 없지만),
UBI 가 wear leveling 을 완벽히 구현하고 있고,
이 위에 올라가는 유일한 파일시스템인 UBIFS 가 journaling/log 를 해내고있습니다.
하지만, 부담스러울 정도로 사용법이 복잡하죠.
JFFS2 같은 경우
JFFS2 같은 경우 엄밀히 말하면 저널링 파일 시스템이라기보다는 로그 기반입니다.
(여기서 착안해서 LogFS라는 개발 중인 파일 시스템은 로그 기반이 아니라 저널링 방식이라는군요.)
어쨌든 이러한 방식들을 사용하는 이유는 영역당 쓰는 횟수에 제한이 있기 때문에,
최대한 쓰기를 분산시키기 위해서입니다. (자연스럽게 분산이 되죠.)
또 scalability 문제도 있구요.
http://en.wikipedia.org/wiki/Flash_file_system
Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.
erase를 해야 하기 때문입니다.
HDD의 경우, disk에 '섹터 n에 데이타를 기록해' 라고 하면,
그냥 기록됩니다.
그러나 플래시메모리의 경우는 좀 다릅니다.
무언가를 기록하기 전에 해당 block에 erase되어 있어야 합니다.
근데, 여기서 문제가 또 발생합니다.
read/write는 block단위로 가능한 반면, erase는 page단위로밖에 할 수 없습니다.
한 page는 다수(이게 보통 32개인가요?)의 block으로 되어 있죠.
이러다보니, 가령, 이런 경우가 발생합니다.
107번 block에 뭔가를 write하고 싶다면,
107번을 제외한 96~127번 사이의 유효한 block을 다른 빈 block을 찾아서
이동시킨 후, 96~127번 block (3번째 page가 되겠죠)를 erase하고
107번에 write를 해야 합니다. 엄청 번거롭죠.
(도대체 이딴 방식의 플래시 메모리가 왜 발명된 건지....)
어쨋건, 여기서 문제가 생깁니다.
HDD의 경우, sector i/o에 있어서의 원자성(이걸 원자성이라고 해야 하나요?)은
유지가 되는 반면, flash memory에서는 그게 유지가 안됩니다. 위에서 설명한 erase하는 과정에서
시스템이 꺼지게 되면, flash memory 자체가 엉망이 되어 버리기 때문이죠.
그래서, 이런 것을 안정적으로 유지하기 위해서
몇가지 테크닉을 사용합니다. i/o transaction을 logging하는 방식으로 구현한다던가,
journal이라는 여분공간을 운영해서 한다던가....
참.
그리고, 한가지 더 있습니다.
flash memory는 수명이 있어서, 이 수명이 넘어가면 해당 page가 bad block으로 갈 확률이 높아지죠.
그래서, 각 page에 erasing count를 세서, 특정 page가 집중적으로 사용되지 않도록
구현될 필요가 있습니다. 즉, block remapping이 필요하다는 거죠.
상위 layer에서 'n번 page에 write해'라고 해도, 사실은 이제 m번 page에 mapping되도록 하는 겁니다.
뭐... 이것을 웨어레벨링이라고도 하는 것 같고요. 보통, FTL 이라고 하면, 이걸 하는 layer를 말할 겁니다.
어쨋건, 그래서 그렇습니다.
플래시메모리에서 ext3같은 block device 기반의 파일시스템을 사용하려면, FTL 역할을 해주는 놈이 있어야 할 거고, 아니라면, jffs2나 yaffs같은 플래시메모리기반의 파일시스템이 필요한 겁니다.
inode (map?) 를 hdd 에
inode (map?) 를 hdd 에 저장하는 방식으로 하면 좀 쉬울것 같은데,
누가 그런 생각은 안할까요?
그렇게 하면 바쁠 때 erase 를 전혀 안할 수 있을텐데 말이죠.
영역별 erase 횟수를 카운트하면서 관리까지 해 주면 더 좋고요.
emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇 개 안돼요~
http://xenosi.de/
https://xenosi.de/
위에 drinkme 님께서 잘
위에 drinkme 님께서 잘 설명해 주셨습니다.
쉽게 말하자면 모든 문제의 근본은 플래시는 Overwrite가 안되기 때문입니다.
아! 좀더 정확히는 NAND Flash는 Overwirte가 안되기 때문입니다.
그래서 지우고 다시 써야 하는데,
또 웃긴것이 NAND Flash는 지우는 단위가 읽고, 쓰기하는 단위보다 약 64배 정도 큽니다.
즉, 한 데이터를 Overwrite하기 위해서는 전혀 상관없는 64개의 영역이 지워졌다가 다시 써져야 합니다.
이거 엄청난 낭비죠.
게다가 지우고 쓰고 하는 횟수도 제한되어 있습니다. 대략 10만번 정도죠.
어느 한 데이터에 계속해서 Update가 발생하면 계속 지웠다/썼다를 반복해야 하는데, 이러면 전혀 상관없는
다른 데이터들까지 사용하지 못하는 사태가 발생합니다.
그래서 Overwrite를 안하고 Update되는 정보를 다른쪽에 쓰고 매핑 테이블 같은걸 만들어서 위치를 알려주는 계층이 필요하죠.
이 계층을 FTL(Flash Translation Layer 스펠링은 맞는지 모릅니다..^^)라고 합니다.
FTL에 대한 여러가지 구현 방법이 있는데 대부분 어떤 식으로든 log를 기록합니다. 자세한건 논문 수준의 내용이 필요합니다.^^
더불어 NAND Flash는 한 번에 쓸 수 있는 데이터 크기가 2Kbyte 짜리인게 대세인 반면 HDD의 sector는 512byte기 때문에 인터페이스 호환을 위해서 FTL에서 이런걸 버퍼링해서 2Kbyte로 만들어주고 어쩌구 하는 작업도 필요합니다.
버퍼링 도중 갑자기 전원이 나가면 또 문제가 되기 때문에 복구해주는 작업도 필요하고...
그래서 NAND flash 파일 시스템은 저널링으로 구현됩니다. FTL의 구현 자체가 기본적으로 저널링 파일 시스템의 원리를 따르고 있을 뿐더러 저널링으로 구현하지 않으면 NAND Flash를 제대로 사용할 수 없기 때문입니다.
----------------------
얇은 사 하이얀 고깔은 고이 접어서 나빌레라
----------------------
얇은 사 하이얀 고깔은 고이 접어서 나빌레라
댓글들이 가면
댓글들이 가면 갈수록 그럴싸해지는군요 ㅎㅎ
journaling 파일시스템은 예기치 않은 power fail 때 파일시스템이 망가지는 것을 방지해줍니다.
파일 단위로는 어떤 것도 보장하지 않습니다. 지워질 수도 있고, 예전 내용이 되살아날 수도 있고...
wear leveling 은 윗분들이 말씀하신대로 각 erase block 들의 erase 횟수가 같아지도록해서
결과적으로 NOR/NAND 플래시의 수명을 연장시키기 위해 필요합니다.
wear leveling 을 FTL 수준에서 구현하는 것은 쉽지만,
journaling/log 를 FTL 수준에서 구현하는 것은 불가능에 가깝습니다.
그 유명한 ext3 에서 사용하는 jbd 조차도 수많은 함수를 export 해서 파일시스템이 그걸 사용해야만 하는 구조입니다.
파일 시스템수준에서 저 둘을 제대로 구현한 것은 아직 없습니다.
JFFS2 는 log 기반이며, wear leveling 은 random 을 사용하는 방법으로 수학적인 균일분포를 주장하고 있습니다.
LogFS 가 journaling 을 구현했다고는하지만, 논문용 파일시스템수준에서 그치고있기 때문에
도저히 현장에서 써먹을만한 정도의 성능이 나오지 않습니다. CPU 도 겁나게 쳐먹고.
FTL 까지 포함해보자면 (오픈소스에서는 사실 선택의 여지도 없지만),
UBI 가 wear leveling 을 완벽히 구현하고 있고,
이 위에 올라가는 유일한 파일시스템인 UBIFS 가 journaling/log 를 해내고있습니다.
하지만, 부담스러울 정도로 사용법이 복잡하죠.
OTL
댓글 달기