FTL

FTL

 

FTL이란 Flash Translation Layer의 약자로, 플래시 메모리의 특성을 감추면서 하드디스크의 기능처럼 수행할 수 있도록하는 소프트웨어층을 의미합니다. 하드디스크에는 물리적인 섹터가 존재하지만, SSD에는 페이지와 블록만 존재합니다. 하지만 NTFS, FAT 같은 파일 시스템과 운영체제는 섹터 기반으로 동작하기 때문에 이러한 한계점을 FTL이 물리적 구조를 논리적 구조로 변환하여 호환성 문제를 해결합니다. 즉 호스트의 논리적 블록 주소(LBA)를 플래시의 물리적 블록 주소(PBA)로 매핑하는 것입니다.

 

FTL을 설명하기 앞서 펌웨어 아키텍처를 간단히 살펴보겠습니다. 

 

먼저 호스트 인터페이스 층(HIL)에서 호스트의 I/O를 담당합니다. 예를 들어, 호스트에서 LBA에 데이터를 write 명령이 왔을 때 호스트에서 전송한 명령어가 큐에 저장되고, 명령어를 Buffer Manager에 가져와 최적화합니다. 여러개의 명령어를 합쳐서 처리한다고 생각하시면 됩니다. 이 후 최적화된 명령아가 Event Queue에 들어오게 되는데, 큐의 특성상 먼저 들어온 명령어 순서대로 처리합니다. 이후 호스트 인터페이스 층을 거쳐서 FTL에 도착하게 되면,  Address Translation, Bad Block Management, Wear Leveling, Garbage Collection 등의 일을 수행합니다. 이후 FIL(Flash Interface Layer)에서는 FTL에서 넘겨준 I/O 작업들을 받아 플래시 메모리 작업을 하게 됩니다.

 

 

Addressing Translation

 

FTL의 기능 중 주소 매핑에 대해서 알아 보겠습니다. 

 

예를들어 "100번지에 write해라"라는 명령이 내려오면, 매핑 테이블에 가서 "100번지는 사실 NAND Flash에서는 200번지야"라고 말해주고, 200번지에 가서 데이터를 write하는 과정입니다. 여기서 100번지는 LBA가 되는 것이고, 200번지는 PBA가 됩니다. 앞서 살펴봤듯 FTL은 파일 시스템으로부터의 논리적 주소를 NAND Flash의 물리적 주소로 매핑하는 과정이기 때문입니다. 

 

하지만 만약 100번지에 쓰기 명령을 받아서 200번지에 갔더니 이미 데이터가 존재한다면 어떻게 될까요? 그러한 경우 새로운 페이지에 가서 데이터를 쓴 후, 매핑테이블에 100번지는 사실 NAND Flash에서는 200번지야 라는 것을 300번지(새로운 페이지)야라고 바꿔주면 되는 것입니다. 이러한 과정을 거치면 결국 200번지는 garbage 데이터가 됩니다.

 

 

Characteristics of NAND Flash

 

하지만, 여기서 "200번지에 다시 쓰면 되는 거 아니야?"라는 의문이 생기게 됩니다. 하지만 플래시 메모리의 특성 상 overwrite을 지원하지 않습니다. 소위 erased-before-wrie이라는 중요한 특성을 가지는데, write을 위해서는 무조건 그 전에 erase를 수반해야합니다. read와 write의 경우 페이지 단위로 수행되지만, erase의 경우 블록 단위로 수행되기 때문에 블록 단위로 erase를 할 때 유효한 페이지 데이터는 내부 레지스터로 백업한 후, 새로운 free상태의 페이지에 기록해야 합니다.

 

같은 위치에 overwrite하는 것은 오버헤드가 굉장히 크므로 실질적으로 플래시 메모리에서는 overwrite을 지원하지 않습니다. 업데이트를 하기 위해서는 free page에만 가능하기 때문에 NAND Flash는 OOB area에 페이지의 valid, free, invalid 정보를 마킹합니다. 또한 Logical Page Number(LPN)을 저장합니다. 이는 "LPN의 100번지는 NAND Flash의 실제 주소인 200번지에 적어놨으니, 200번지에 가서 읽어 가져와주고 그것이 100번지라고 말해줘!"라고 간단히 이해하시면 됩니다. 이러한 매핑테이블은 DRAM에 저장합니다.

 

 

Mapping Schemes

 

Page-level mapping

 

Page-level mapping은 페이지 단위로 매핑 테이블을 구성합니다. 페이지 단위로 매핑 테이블을 만들기 때문에 매핑 테이블 자체가 아주 많은 메모리 공간을 요구하는 단점을 지닌 반명 유연성과 성능이 매우 좋습니다.  Page-level mapping은 페이지 매핑 테이블을 통해 LPN(Logical page numver)을 PPN(Physical page number)으로 변환합니다.

 

 

예를 들어 LPN 9에 write하게 되면, LPN 9는 PPN의 6에 해당함을 매핑 테이블에 업데이트를 합니다. 

LPN 3에 write하는 경우도 동일합니다, LPN 3은 PPN 7에 해당함을 매핑테이블에 업데이트하면 됩니다. 하지만, LPN 5에 write하는 경우에는 PPN 5에 이미 데이터가 존재하기 때문에 PPN 5를 invalid 상태로 변경 후 다른 페이지에 write을 수행합니다. 그 후 LPN 5는 PPN 8에 해당함을 매핑테이블에 업데이트 합니다.

 

 

Page-level mapping의 경우 비어있는 페이지에 write을 수행하고 매핑 테이블만 변경해주면 되므로 유연성의 장점을 가집니다. 하지만 오버 프로비저닝의 크기에 민감하다라는 단점을 가지는데, 오버 프로비저닝은 시스템 성능을 저해하지 않고 SSD에서 삭제할 데이터에 대해 특별히 추가 용량을 제공하는 기능입니다. SSD 특성상 저장된 데이터를 덮어쓸 수 없기 때문에 erase를 항상 수반하게 되는데, 이때 valid data는 OP에 옮긴 후 invalid data를 지워서 업데이트 하기 때문에, OP의 공간이 작을 수록 erase 작업을 더 많이 수행해야하므로 OP의 공간이 클 수록 유리해집니다. (erase 작업은 write과 read에 비해 100배 정도 느립니다.) 또한, 페이지 레벨 매핑의 경우 페이지 전체를 스캐한 후에 매핑 테이블을 재구성해야하여 시간 소요가 많다는 단점을 지닙니다.

 

 

Block-level mapping

 

Block-level mapping은 블록 단위로 매핑 테이블을 구성합니다. 블록 레벨 매핑은 적은 메모리 공간을 요구하는데, 이는 SSD 드라이브가 256개의 페이지를 가지고 있다면 블록 단위의 매핑은 256배의 적은 메모리를 필요로 하기 때문입니다. 즉 ( 1 / 페이지 의 수 )만큼의 메모리를 사용하게 됩니다. 하지만 페이지 하나만 기록되어도 될 정도의 작은 데이터를 자주 업데이트하는 경우 블록 단위로 통째로 기록해야하므로 불필요한 쓰기가 발생하여 상대적으로 성능이 낮습니다.

 

블록 레벨 매핑의 경우 LPN을 LBN으로 변환 후, LBN을 PBN으로 변환합니다. 

 

1) LPN -> LBN + page offset

 

- LBN = LPN / N  (N : 블록 내의 페이지 수)

- page offset = LPN % N

 

2) LBN -> PBN

 

왼쪽 사진에서 LPN 9에 write을 수행하면 LBN = 9/4 = 2 , offset = 9%4 = 1 이므로 LBN 2에 해당하는 PBN이 1 이므로 PBN 1로 이동 후 offset 1에 9를 write 합니다. 오른쪽 사진의 경우 LPN 5에 write을 수행하면 LBN = 5/4 = 1, offset = 5%4 =1 이므로, LBN 1에 해당하는 PBN 2로 이동하여 5를 write하려 해는데 이미 데이터가 존재하므로 기존 데이터는 invalid 상태로 변경하고, 새로운 페이지에 write해야합니다. 하지만 블록 레벨 매핑의 경우에는 기존의 valid data도 offset을 유지해야하는 특성을 지니기 때문에 5 뿐 아니라 4도 같은 블록으로 copy해주어야 합니다. 이러한 특성을 가지기 때문에 random write의 경우 성능이 좋지 않습니다. 

 

 

학부생의 입장에서 작성한 포스팅이므로 틀린 부분이 있다면 댓글 남겨주세요 :)