AngelPlayer`s Diary

기본 오퍼레이션

NAND Flash Memory 특성상 특정 셀을 단독으로 읽고 쓰는 작업이 불가능함

 

- 읽기는 페이지 사이즈 단위로 실행

한 바이트만 읽도록 요청을 보내도 실제 SSD는 하나의 페이지를 통째로 읽은 후 해당 바이트만 반환

 

- 쓰기는 페이지 사이즈 단위로 실행

읽기와 마찬가지 한 바이트만 쓰더라도 전체 페이지가 기록(사용)되어야 한다.

 

- 페이지는 덮어쓰기 될 수 없다

NAND Flash Memory 페이지는 반드시 Free 상태일때만 쓰기가 가능하다.

데이터가 변경되면 페이지의 내용을 레지스터로 복사 후, 레지스터에서 변경하고 새로운 Free 상태의 페이지에 저장하는 방식 (Read-Modify-Write 방식) -> SSD는 다른 페이지로 이동하지 않고 변경될 수 없음

새로운 페이지에 변경된 데이터가 기록되면, 원본 페이지는 Stale 상태가 되고, 삭제(Erase) 되기 전까지 그 상태로 남아있음

 

- 삭제는 블록 사이즈 단위로 실행

페이지는 덮어쓰기가 불가능 하기 때문에 stale 상태인 페이지를 삭제 작업을 거쳐 Free 상태로 만들어 주어야 함

삭제는 블록 단위로 진행되기 때문에 단일 페이지로 지울 수 없음

사용자는 읽기와 쓰기 명령만 데이터 엑세스를 위해서 사용할 수 있고, 삭제 명령은 SSD 컨트롤러가 Free 공간이 필요할 때 자동으로 실행 (Garbage-Collection)

 

 

 

 

쓰기 예제

1. 초기 설정

2000번 블록은 Free 상태, 1000 블록은 3개의 used 페이지와 free 페이지로 구성

(PPN == 물리 페이지 번호)

 

2. 페이지 쓰기

1000번 블록의 PPN=0 페이지를 x^2로 업데이트 하려고 할 때, 페이지는 덮어쓰기가 불가능 하기 때문에 기존 PPN=0 페이지는 stale 상태로 바꾸고, 새로운 데이터를 PPN=3페이지에 기록한다.

 

3. Erashing a block

GC는 1000번 블록의 유요한 데이터를 2000번 블록에 복사하고, 1000번 블록을 지운다.

블록은 정해진 횟수 (P/E 사이클)만큼만 삭제 가능하다.

 

 

 

 

Write amplification (쓰기 확대)

쓰기는 페이지 사이즈에 맞춰서 실행되므로, 페이지의 사이즈에 맞지 않는 모든 쓰기 명령은 필요 이상의 부가적인 쓰기(Write amplification)가 일어난다. 1 byte 쓰기 명령이 일어나면, 페이지 사이즈가 16kb인 SSD는 1byte 기록을 위해 16kb를 기록해야 한다

 

역으로 필요 이상의 데이터를 쓰게 되면, 필요 이상의 내부 오퍼레이션을 유발시킨다.

페이지 크기에 맞지 않는 쓰기는 해당 페이지의 데이터를 캐시로 읽고, 다시 페이지에 기록하기 때문에 즉시 페이지에 기록하는 것 보다 느리게 작동한다. (read-modify-write)

 

- 페이지 사이즈보다 작은 데이터 쓰기 피하기

앞의 두 단점을 최소화하기 위해서 NAND 플래시 페이지 크기보다 작은 데이터의 쓰기는 피하도록 한다.

 

- 쓰기 맞춤

데이터의 쓰기는 단일 페이지 크기에 맞추거나, 여러 페이지 크기에 맞춰서 실행한다.

 

- 작은 데이터의 쓰기는 버퍼링

스루풋을 최대화하기 위해서, 작은 쓰기는 메모리에 버퍼링 했다가 버퍼가 가득 차면 단일 쓰기로 최대한 많은 데이터를 기록

 

 

 

Wear leveling (분산 쓰기)

NAND 플래시 셀은 프로그램 삭제(P/E Cycles)이 제한되어 있음 -> 제한된 수명을 가진다.

모든 셀이 균일하게 P/E Cycles이 분산되어 한계점(Wearing off)에 거의 동시에 도달하게 하는 것이 SSD 컨트롤러의 중요한 역할 중 하나

 

 

 

 

 

FTL

SSD 컨트롤러 내부에 위치 

논리적 블록 매핑(LBM)과 Garbage-Collection 2개의 중요한 부분을 담당

 

 

논리적 블록 매핑(Local Block Mapping)

호스트 영역의 논리 주소를 NAND 플래시 메모리의 물리 주소로 변환해주는 역할

블록 매핑은 LBA와 PBA로 구성된 테이블(mapping-table)을 가지며, 이 매핑 테이블은 ssd의 ram과 ssd의 플래시 메모리에 저장됨

ssd의 전원이 켜지면 플래시 메모리에 저장된 매핑 테이블을 읽어서 ram에 로딩

 

 

페이지 단위로 매핑 테이블 구성(Sector Mapping) - 유연하지만 매핑 테이블 자체가 많은 메모리를 소모

블록 단위로 매핑 테이블 구성(Block Mapping) - 작은 데이터를 자주 업데이트 하는 경우 불필요한 쓰기가 자주 발생

-> Hybrid 매핑을 사용하자

 

 

Hybrid Log-block FTL (차후 다시 정리)

유입되는 쓰기 오퍼레이션은 로그 블록에 기록, 로그 블록이 꽉 채워지면 동일한 LBN을 가지는 블록의 데이터와 병합하여 새로운 free 블록으로 기록

 

 

 

 

Garbage Collection

데이터가 업데이트 될 때 새로운 버전의 데이터는 free 페이지에 기록되고, 기존의 데이터가 기록된 페이지는 stale 상태가 된다.

블록이 stale 상태의 페이지를 가지고 있다면, 그들을 재사용하기 위해 삭제(Erase) 작업이 필요하다.

 

쓰기 오퍼레이션(250 ~ 1500 마이크로 초)에 비해서 블록을 삭제(Erase)하는 과정(1500 ~ 3500 마이크로 초)은 많은 시간이 소요 -> 일부 컨트롤러는 백그라운드 GC를 도입

백그라운드 Garbage-Collection은 Idle Collection으로도 알려져 있으며, SSD가 한가한 시간에 stale 페이지를 free 상태로 만들어줌

일부는 Parallel Garbage-collection 방식을 구현, 호스트의 쓰기 요청과 동시에 Garbage-collection을 실행

백그라운드 오퍼레이션은 포그라운드 오퍼레이션에 악영향을 미칠 수 있다. (작은 데이터의 랜덤 쓰기가 지속적으로 발생하는 시스템에서 특히)

 

 

읽기는 주의 셀들의 상태를 변경시킬 수 있기 때문에, 블록은 일정 회수 이상의 읽기가 수행된 이후 다른 위치로 옮겨져야 한다.

 

 

 

빈번하게 변경되는 데이터를 핫(Hot) 또는 동적(Dynamic) 데이터라고 하며,

반대인 데이터를 콜드(Cold) 또는 정적(Static)데이터 라고 한다.

 

핫 데이터와 콜드 데이터는 최대한 분리시켜야 GC를 효율적으로 처리 할 수 있다.

Wear-leveling을 위해서 콜드 데이터와 핫 데이터를 가진 페이지를 주기적으로 스왑할 필요가 있다.

 

핫 데이터는 최대한 버퍼링되었다가 SSD에 덜 자주 업데이트되도록 하는 것이 좋다.

 

불필요한 데이터는 최대한 모아서 한 번에 삭제하는 것이 좋다.

 

 

 

 

 

 

 

 

 

- 참고 문헌 -

tech.kakao.com/2016/07/15/coding-for-ssd-part-3/#fnref:9

공유하기

facebook twitter kakaoTalk kakaostory naver band