[SPDK] Nand Flash SSD Internals

Solid State Devices (SSD)

SSD는 복잡한 알고리즘에 의해 관리되는 저장장치로 사용 방식에 따라 성능이 천차만별이다. 본 글에서 다루는 내용은 소프트웨어 개발자들이 SSD 내부 동작을 쉽게 이해하고 더 나은 소프트웨어 설계를 할 수 있도록 돕기 위해 작성되었다. 내용들은 간소화 된 것으로 실제 SSD 하드웨어 내부에서 일어나는 일과 동일하다고 가정해서는 절대 안된다.

이 글이 작성되는 시점을 기준으로 SSD 는 보통 NAND Flash 메모리로 구성된다. Nand 메모리는 아래와 같은 몇가지 중요한 특징이 있다.

• Nand 메모리는 그룹화 되어 NAND die라고 불리는 칩을 구성하며, 각 칩들은 병렬적으로 동작할 수 있다.
• Nand 메모리에 저장되는 bit를 flip 하는 작업은 비대칭 적이다. 한 방향으로의 flip 은 매우 쉬우나, 그걸 다시 되돌리기는 상대적으로 어려운 특성이 있다. (이후 더 설명됨)

Basic Structure

Nand 플래시 메모리는 작은 유닛 단위 그대로 사용되는 게 아니라 erase blcok 이라고 호칭되는 큰 단위의 유닛으로 묶여서 사용된다. erase block의 크기는 하드웨어 구현에 따라 달라지지만, 보통 1MiB 에서 8MiB 사이이다. 각 블록들에 존재하는 각각의 bit 들은 bit 단위로 단 한번만 program (0 to 1) 될 수 있다. 같은 bit에 다시한번 데이터를 program 하기 위해서는 erase block 전체를 먼저 erase (erase block의 모든 bit를 0으로)해야 한다. 이러한 erase 작업이 위에서 2가지 특징으로 설명했던 부분중 asymmetric (비대칭) 특성에 해당한다. block erase 작업은 해당 낸드 미디어를 마모시키며, 이로 인해서 각 블록은 제한된 횟수 만큼만 erase 될 수 있다.

FTL

아래의 내용은 SPDK 가 구현하는 FTL 을 기준으로 한다.

write (program) operation

SSD 가 호스트에 연결된 경우 512B나 4KiB 단위의 고정 길이 logical block으로 구성된 블록 디바이스 인 것처럼 보이는 인터페이스를 제공한다. 이러한 고정 길이 logical block들은 디바이스 펌웨어가 임의로 구성하는 크기 이며, 낸드 메모리의 물리적 위치에 정적으로 매핑되지 않는다. 각 논리 블록들에 대한 write 요청이 들어올 경우 해당 데이터가 전에 쓰인 위치는 신경쓰지 않고 nand flash의 완전히 새로운 영역에 데이터를 쓴 뒤 L2P 정보를 새로운 영역으로 갱신한다. 이러한 새 쓰기 영역을 결정하는 알고리즘이 SSD 성능에 영향을 미치는 주요 요소이며, flash translation layer (FTL) 이라고 부른다. FTL은 모든 블록 미디어가 유사한 수준으로 마모 되도록 wear-leveling 을 해야 하며 병렬성을 이용하여 전체 성능을 증가 시키기 위해 여러 NAND die chip으로 IO를 잘 분산시켜야 한다. 가장 간단한 FTL 모델로는 RAID 시스템 처럼 각 die chip을 하나의 구성 요소로 보고 전체 die chip을 대상으로 데이터를 분산 seq write 하는것이다. 실제 SSD는 이보다 훨씬 복잡한 알고리즘을 사용하지만 소프트웨어 개발자들이 이해하는 데는 이정도면 충분하다.

read operation on unmapped data

FTL을 통해 L2P 맵을 유지하고 애플리케이션이 사용하는 logical 주소와 실제 낸드의 physical 주소가 다르다는 점을 이용하는 L2P unmap 동작도 존재한다. NVMe 에서는 deallocate, SCSI 에서는 unmap, SATA에는 trim이 그 커맨드이다. 매핑 되지 않은 데이터에 read를 시도하는 경우 아래와 같은 두가지로 처리할 수 있다.

1. 실제 nand read나 dram transfer를 수행하지 않고 곧바로 success 로 처리한다. 어차피 device가 전달하는 데이터는 의미 없는 데이터 이기 때문에 이렇게 처리해도 상고나없다.
2. 0으로 초기화된 데이터를 리턴한다.

첫 번째 방법이 훨씬 일반적이며 실제로 unmap 된 영역의 데이터에 대한 read를 ssd에 요청할 경우 디바이스가 제공 가능한 대역폭보다 훨씬 높은 성능을 나타내는 경우를 볼 수 있다. 이러한 mis-read 성능을 방지하기 위해서는 벤치마킹을 수행하기 전에 대상이 되는 모든 데이터 영역을 미리 write해야 한다.

Garbage Collection

SSD에 계속 해서 데이터가 쓰일 경우 log 형태로 기록하는 특성상 결국 유저 스페이스에 비해 적은 양의 데이터로 ssd 내부 공간을 가득 채우게 될것이다. 이러한 경우에도 사용자의 쓰기 요청을 계속 해서 수행할 수 있도록, 내부의 불필요한 데이터를 삭제하는 작업이 필요하다. 이러한 작업을 수행하는 것을 Garbage collection (GC) 라고 부른다. 모든 SSD를 GC를 위해 일정 공간의 erase block을 남겨 놓으며 이 공간을 GC 수행 시 사용한다. GC는 보통 아래와 같은 순서로 수행된다.

1. GC를 수행할 대상 erase block을 선정한다. 가장 좋은 방법은 LRU 방식이다. (나중에 설명하겠지만 다른 여러가지 방법이 있다.)
2. 대상이 된 erase block의 모든 페이지들에 대해서 해당 페이지가 다시 쓰이지 않은 완전히 유효한 최신 페이지 인지 확인 한다. (가장 최신 로그인지 확인 하는 등, FTL에 따라 확인 방법은 다를 수 있다.)
3. 유효한 페이지로 판단 된 경우 해당 페이지를 메모리로 읽어 들인 뒤 GC를 위해 남겨둔 블록으로 이동시킨다. (또는 현재 로그를 기록하는 블록으로 이동, 이 또한 FTL에 따라 방법이 다르다.)
4. 스텝 2, 3을 erase block의 마지막 페이지에 도달할 때 까지 반복하고, 모두 완료된 이후에 해당 블록을 erase 하여 free block으로 전환한다.

GC를 할 때 모든 페이지가 유효하지 않은 페이지일 경우 스텝 3을 건너 뛰고 바로 erase를 수행할 수 있어서 매우 효율적으로 끝낼 수 있다. 이러한 상황을 자주 만들기 위해서는 2가지 방식을 사용할 수 있다. 첫 번째는, GC를 위해 남겨두는 블록의 개수를 실제 유저가 사용하는 블록의 개수보다 많게 만드는 것이다. 이러한 영역을 우리는 over-provisioning (OP) 영역이라고 부른다. 이러한 방식을 통해서 대부분의 로그가 OP에 흡수되어 GC 발생 시 대상으로 선정된 블록에 유효한 페이지가 거의 남아있지 않도록 하는 것이다. 두 번째로는, 소프트웨어 자체에서 장치에 순차 쓰기를 진행하면서 circular use 패턴을 유지하고, 사용되지 않는 데이터에 대한 정보를 미리 알려 주는 것이다.

Over-Provisioning

OP의 양을 조절하는 것은 성능에 곧바로 영향을 주게 된다. 특히, 장치가 데이터로 가득 차 있는 경우에는 영향이 더욱 크다. OP를 장치 내부에서 조절하지 않고 소프트웨어 레벨에서 조절해도 이와 동일한 효과를 얻을 수 있다. 이 점을 잘 이해해야 성능 평가 등을 진행할 때 일정한 평가 결과를 얻을 수 있다. 특히, GC가 백그라운드로 동작하지 못하고 매 write 마다 on-demand로 진행해야 하는 경우 io latency가 급격하게 증가할 수 있는 문제가 있다. 벤치마크 수행 시 이러한 사항을 일정한 수준으로 동일하게 만들어내는 것이 중요하다. 보통 장치 전체를 순차 쓰기로 가득 채우는 작업을 2번 반복하는 것으로 이를 수행할 수 있다. 자세한 초기화 방법은 SNIA Article을 참조하기 바란다.