3. DFTL: a flash translation layer employing demand-based selective caching of page-level address mappings

[busanlinux]

Motivation

이 논문은 FTL의 매핑 방식의 과도한 메모리 사용 및 빈번한 Erase 동작 특히 Merge 과정에서 많은 Cost가 발생하는 Full Merge 동작을 안하여 FTL의 Mapping 기능의 성능을 최적화 하려고 한다.

Proposal

기존 하이브리드 매핑 방식에서 사용 되던 Log Block을 사용하지 않고, Page-Level 기반 Translation Block, Global Translation Directoey(GTD), Cache Mapping Table(CMT)라는 새로운 구조를 사용하여 Logical -> Physical Translation 을 제안한다. CMT를 통해 기존 Page-Level Mapping 방식에서 Mapping Table에 의한 과다한 RAM 사용 문제를 줄일 수 있으며, 시간적 로컬리티 활용이 가능하다.

Results

기존에 사용하던 Page, Block, Hybrid Mapping 방식에 비해 거의 모든 면에서 성능이 우수하다. 특히 Hybrid Mapping에서 사용되는 Full Merge를 사용하지 않는 것을 알 수 있었다.. 추가적으로 RAM 크기가 커짐에 따라 CMT의 Hit율이 증가하여 성능 향상이 되며, Response Time이 줄어든다. 하지만 Read-Dependency한 Workload에서는 Translation Cost가 많이 발생해서 Hybrid Mapping과 비슷한 추가적인 Read/Write가 발생한다

[min-seong-kim]

3.4장에서 state-of-the-art FTL과 DFTL을 비교해 DFTL의 장점만 보여줬는데 DFTL의 단점은 무엇입니까?

[neokkk]

논문에서 제안하는 방식이 page-level mapping이라고 주장하고 있는데, 넓은 관점에서 보면 GTD가 일종의 block mapping을 담당하여 hybrid 방식이 되는 것이 아닌가요?

[JustYOLO]

3.4장에서 state-of-the-art FTL과 DFTL을 비교해 DFTL의 장점만 보여줬는데 DFTL의 단점은 무엇입니까?

DFTL이 sate-of-the-art FTL와 비교해서 가지는 단점은

1. Cache에 존재하지 않을 경우 추가적인 latency 발생
2. 비교적 구현이 어려움 (cache, translation block 등) 등이 존재할 것 같습니다

[kbskbs1102]

request가 SRAM에 존재하지 않을 경우, 다른 매핑 테이블을 업데이트하고 request를 반환하는데 이러면 유저 입장에서는 기다리는 시간이 길어질 것 같습니다. 유저의 request를 먼저 처리하지 않는 이유가 있을까요?

[JustYOLO]

논문에서 제안하는 방식이 page-level mapping이라고 주장하고 있는데, 넓은 관점에서 보면 GTD가 일종의 block mapping을 담당하여 hybrid 방식이 되는 것이 아닌가요?

논문의 Section 3에서 말하듯: "Page-level mappings allow requests to be serviced from any physical page on flash. However, to make the fine-grained mapping scheme feasible with the constrained SRAM size, a special address translation mechanism has to be developed."

그리고 hybrid mapping을 다음과 같이 말하고 있습니다: "... most of the blocks (called Data Blocks) are mapped at the block level, while a small number of blocks called “update” blocks are mapped at the page level and are used for recording updates to pages in the data blocks."

따라서, DFTL은 page-level mapping의 정의에도 정확하게는 맞지 않고, hybrid mapping의 정의에도 정확하게 맞지 않는 것 같습니다. 하지만, 기본적인 mapping 방식이 page 단위로 진행되다보니, 저자가 DFTL을 page-level mapping으로 설명하고 있다고 생각됩니다.

[JustYOLO]

request가 SRAM에 존재하지 않을 경우, 다른 매핑 테이블을 업데이트하고 request를 반환하는데 이러면 유저 입장에서는 기다리는 시간이 길어질 것 같습니다. 유저의 request를 먼저 처리하지 않는 이유가 있을까요?

이는 논문에서 언급된 temporal locality와 관련이 있을 것 같습니다. Mapping table을 먼저 update 함으로서 생기는 이점은, temporal locality에 특성에 의해 이후에 들어오는 요청이 동일한 entry를 사용할 것이라는 예측에 비롯해서 성능을 향상 시킬 수 있다고 생각됩니다. 따라서 workload에 특성에 따라 다르겠지만, temporal locality가 높은 특성을 가진 workload에서는 성능이 더 좋을 것이라고 생각됩니다.

[Student5421]

DFTL 논문에서는 DFTL과 Ideal Page FTL과의 차이를 업데이트 가능한 블록 관점에서 설명하고 있습니다. DFTL은 업데이트 가능한 블록이 Data 블록에 한정되는 반면, Ideal Page FTL은 시스템 내의 모든 블록 즉, Data 블록과 Log 블록이 모두 업데이트에 사용될 수 있다고 설명되어 있습니다. 이 차이가 어떤 의미가 있고, 성능에서 어떻게 나타나고 있나요?