Paper Review : DFTL(Demand-based Flash Translation Layer)

⏳ DFTL: A Flash Translation Layer Employing Demand-based Selective Caching of Page-level Address Mappings
Aayush Gupta, Youngjae Kim, Bhuvan Urgaonkar
Department of Computer Science and Engineering, the Pennsylvania State University

---

- SSD 기본 개념 (참고)

 

OSTEP Review : 44장 Flash-based SSDs

---

-  🔎 현재 Flash Memory의 문제

1. 순차 접근에서 HDD보다 성능이 떨어질 수 있음 → Hybrid Storage(HDD + SSD 필요)

2. 랜덤 쓰기에서 Performance Bottleneck → FTL의 구조적 개선

 

* HDD : 대용량 데이터 처리와 순차 접근에 유용

   SSD : 랜덤 접근과 성능이 중요한 환경에서 유용 - Erase-before-write / GC

 

-  🔎 FTL의 설계 문제 : Mapping Table 저장용 SRAM

• Page Lv Mapping : 세밀하고 유연하지만 Mapping Table이 커서 SRAM 많이 필요.
• Block Lv Mapping : Mapping Table 작아서 SRAM 적게 필요하지만 Internal Fragmentation과 GC overhead 문제
  
  

- Hybrid FTL의 제안

• Data Blocks은 Block Lv Mapping → SRAM 절약
• Log Blocks은 Page Lv Mapping → 유연한 업데이트 가능
  → SRAM 사용량은 줄여 cost를 챙기면서 유연한 쓰기 가능

• 단점
  
  • Mapping 단위 혼용으로 Full Merge가 필요하다
  • 성능 최적화를 위해 워크로드 특화 파라미터가 필요해 복잡하다
  • 대부분 엔터프라이즈 워크로드에서 나타나는 Temporal Locality를 효율적으로 활용하지 못 한다

---

그래서,

- 💡 DFTL(Demand-based FTL)

 

- DFTL의 특징

1. 페이지 단위 매핑

 페이지 단위 매핑으로 요청을 어떤 플래시 페이지에서도 처리 가능하게 만든다

 

2. 주소 매핑을 선택적으로 캐싱

자주 사용하는(Temporal Locality) 매핑 정보만 CMT(Cache Mapping Table)에 저장하고 나머지는 플래시에 저장한다

OOB(Out-Of-Band) 영역이 아닌 플래시의 데이터 영역에 저장해 더 많은 매핑 정보를 저장할 수 있다

필요할 때만 일부를 SRAM으로 동적으로 로드하는 구조를 가진다

 

3. Data Block과 Traslation Block

기존 로그 블록 개념을 완전히 제거하고 모든 블록을 업데이트 요청 처리에 활용한다

• Data Block : Data Page만 저장
• Translation Block : Translation Page를 포함하는 블록

4. Data Page와 Translation Page

• Data Page :  읽기/쓰기 작업 중에 접근되거나 업데이트 되는 실제  데이터를 포함
• Translation Page : Logical-to-Physical mapping 정보 저장에만 사용됨

5. GMT와 GTD

• GMT(Global Mapping Table) : 전체 매핑 테이블
• GTD(Global Translation Directory) : SRAM 내에서 GMT의 위치 정보를 저장

 

- DFTL에서 I/O 처리

• Read
  : 주소 변환이 완료되면 플래시에서 직접 데이터를 읽어 read 요청을 처리한다
• Write
  : Current Data Block의 다음 빈 페이지에 쓰고 CMT의 매핑을 갱신한다
• GC(Garbage Collection)
  : GC threshold를 설정해 이 한도를 넘기 전까지는 GC 없이 쓰기를 진행한다
  GC threshold를 넘으면 GC가 동작하여 Cost-Benefit 분석을 통해 Victim Block이 결정된다
  victim 블록이 Translation 블록이면 유효 페이지를 Current Translation Block으로 복사하고 GTD를 갱신한다
  데이터 블록이면 유효 페이지를 Current Data Block으로 복사하고 관련된 변환 페이지와 CMT도 업데이트한다
  
  
• 불필요한 작업을 줄이기 위해 Lazy Copying과 Batch Update를 활용한다
  • Lazy Copying : CMT의 매핑만 우선 갱신하고 SRAM에서 해당 매핑이 Eviction될 때까지 Flash에는 변경사항을 반영하지 않음
  • Batch Update : 하나의 변환 페이지에 여러 유효 매핑이 있을 경우 Batch 단위로 한 번에 갱신하여 오버헤드를 줄임, GTD도 함께 갱신

---

 

- Cache Miss의 경우

1. 캐시가 가득 차 있으면 LRU 방식으로 Victim 대상 선택 (segmented LRU 사용)
2.  victim 매핑이 수정되지 않았다면(clear) 그냥 삭제
3. 수정되었으면(dirty) GTD를 통해 해당 매핑이 포함된 변환 페이지 위치 확인
   → 플래시에서 읽고, 수정 후 새로운 위치에 쓰고, GTD 갱신
4. 요청 매핑 정보를 GTD에서 찾고, 해당 변환 페이지를 읽어 CMT에 로딩 후 요청 처리
   
   

- DFTL에서 주소 변환 Overhead (Worst Case)

두 번의 변환 페이지 읽기(하나는 교체 알고리즘에 의해 선택된 vicitim 대상을 위한 것이고 다른 하나는 원래 요청을 위한 것)와

CMT miss가 발생할 때 발생하는 한 번의 변환 페이지 쓰기(for victim)가 포함

 

---

- 기존 FTL과 비교

• Full Merge : DFTL에서는 불필요
• Partial Merge : 기존 hybrid FTL보다 환경에 더 잘 적응함
• Random Write Performance : Full merge가 필요하지 않아 성능 저하가 없음
• Block Utilization : 모든 블록을 업데이트에 사용 가능하기 때문에 활용도가 높음

- DFTL의 장점

• 랜덤 쓰기 성능 : Response Time 개선, GC 감소
• 관리부담 감소 : 기존 FTL과 달리 파라미터 설정이 없다
• 오버로드 처리 : 버퍼 관리 효율성 증가
• 안정적 성능 : 랜덤, 순차 쓰기 모두에서

---