2016년 MIT와 서울대학교에서 공동연구로 진행하여 Fast'16에 발표한 논문이다.
해당 논문에서 제시하는 아이디어는 현재 OCSSD, ZNS와 같은 형태를 보인다.
여기서 말하는 OCSSD는 오픈채널 SSD를 의미한다. 해당 아이디어는 SSD FTL에서 처리하는 기능들을 호스트에서 제어할 수 있게 오프로딩하는 연구이다.
ZNS도 그렇고, 오픈채널 SSD도 그렇게 본 포스트에서 소개하는 연구도 FTL의 기능의 일부분을 호스트로 위임하려고 한다. 왜그럴까? 그러한 문제를 한 번 살펴보자.
FTL의 오버헤드
FTL은 SSD 내부의 컨트롤러에 존재하는 소프트웨어 레이어이다. 호스트의 논리 주소(LBA) 를 NAND의 물리 주소(PBA) 로 매핑해주는 변환기 역할을 주로 수행한다. 혹은 가비지 컬렉션과 웨어 레벨링같은 SSD의 낸드 플래시 칩을 관리하는 역할도 수행한다. 왜냐하면 SSD는 수명이 존해한다.
SSD는 호스트에게 단순한 블록 디바이스로 보인다. 물론 SSD는 단순한 블록 디바이스가 아니다. 이러한 호환을 위해 FTL이 번역을 하고 있기 때문이다. 또한 모든 내부 NAND 관리 (매핑, GC, WL 등)는 SSD 내부의 FTL이 책임진다.
FTL의 치명적인 문제는 블랙박스이다. FTL이 언제 GC를 수행하는지 호스트 레벨에서는 예측이 불가능하다. 이러한 문제가 오버헤드로 누적되고, 본 논문에서 설명하는 "더블 로깅 문제"가 발생하는 것이다.
오픈채널 SSD
해당 제품도 호스트가 워크로드 특성에 맞게 매핑 최적화가 가능하고, GC/WL 스케줄링을 호스트가 직접 제어할 수 있다. 그러면 예측도 할 수 있다.
ZNS
zns는 FTL 레벨 관리를 호스트에서 하는 것은 아니지만, Zone 단위로 쓰기를 통해 랜덤 쓰기를 방지한다. 순차쓰기 덕분에 GC 부담이 거의 없는 것이다.
Applcation Managed Flash
해당 연구에서는 더블 로깅 문제로 인해 발생하는 각종 지연들을 해소하고자 한다.
FTL의 기능을 최소화하고, FTL의 주요한 기능(GC)를 호스트로 옮긴다. 그리고 시스템 호환을 위해 블록 인터페이스와 FTL을 새로운 인터페이스로 구현하여 각각 ALFS, AFTL이라는 이름이라고 명칭한다.
위 그림은 어떤 동작을 하는지 설명하는 이미지지만, 설명없이 본다면 이해할 수 없다.
간단히 설명하면
- 체크포인트 세그먼트
- 아이노드 맵 세그먼트
- 데이터 세그먼트
로 구성된 파일 시스템이 존재하며, 이러한 기능들은 파일 시스템을 최적화하기 위함이다.
zns와 유사하게 append-only 구조로 데이터 쓰기를 채용했다. 이유는 GC가 없기 때문인 것 같다.
위 이미지는 실험 테스트이다. AMF는 저자의 연구팀이 개발한 인터페이스이다. 해당 인터페이스에서 시스템이 상당히 안정된 것을 확인할 수 있고, 다른 PFTL, DFTL은 상용 FTL 구현 비교체이다.
저자는 해당 실험을 수행하기 위해 의도적으로 GC를 많이 발생시켰다고 한다. GC 발생을 위해 SSD 의 용량을 16GB로 제한하고, 호스트 디램 크기는 1.5GB로 제한했다고 한다.
실험 벤치마크는 위와 같다.
기여
의의는 GC없는 시스템 구현에 있으며, F2FS를 기반으로 만들었다는 점이다. 또한 FTL의 문제를 오프로딩함으로서 해결했다는 의의가 있다.
