Some questions about the zftl

[ZhuWeiLin0]

@DingcuiYu
Hello, DingcuiYu:
I read the code about zftl and here are a few questions confusing me. It would be very helpful if you could kindly explain them.

1. Page-level mapping table requires large DRAM. Does it violate the design principle of ZNS? One of the most significant advantages of ZNS is the coarse-grain mapping and low dram usage.

2. When mapping LPN to PPN, physical pages from blocks with the same offset in all planes within the same channel and the same chip are continuously mapped, like below:

Zone 0 layout
|----------LPN0-------------|----------LPN1-------------|----------LPN2------------|....
| PPN0 from Pln0 FC0 Ch0 | PPN0 from Pln1 FC0 Ch0 | PPN0 from Pln2 FC0 Ch0 | ....
It seems that it does not leverage the channel level and chip level parallelism, which makes one write slow.

3. The program unit is ZNS_PAGE_SIZE * flash_type * 2. I think ZNS_PAGE_SIZE * flash_type means we have to write multiple pages if flash_type is not SLC, but why do we have to multiply it by 2?

4. What is the difference between LOGICAL_PAGE_SIZE and ZNS_PAGE_SIZE? Do we have to define their size according to the flash type? For example, QLC means ZNS_PAGE_SIZE should be 4x of LOGICAL_PAGE_SIZE?

Thank you very much!

[DingcuiYu]

Thank you for your question!

1. Use page-level mapping just to get the LPN corresponding to the PPN quickly in the emulator. Even if the page-level mapping is used in real SSDs as well, since consecutive LPNs within the zone correspond to consecutive PPNs, the SSD controller can still aggregate/compress these L2P mapping entries on the L2P cache (usually DRAM) and save space in the L2P cache.

2. A fix for this issue has been committed to my latest pull request.

3. 2 represents the number of planes in each lun. Usually, pages within multiple planes in a chip need to be programmed in parallel. I have modified it to id_zns->planes_per_lun. Considering the lack of understanding of plane-level parallelism, this variable is currently unused.

4. LOGICAL_PAGE_SIZE indicates the host (or operating system) page size, which is typically 4 KiB. ZNS_PAGE_SIZE indicates the flash page size, which is typically 16 KiB. Both values are independent of the media type of the flash memory. The media type of the flash memory affects the programming unit, e.g. QLC requires four flash pages to be programmed at a time.

[ZhuWeiLin0]

Thank you for your question!

1. Use page-level mapping just to get the LPN corresponding to the PPN quickly in the emulator. Even if the page-level mapping is used in real SSDs as well, since consecutive LPNs within the zone correspond to consecutive PPNs, the SSD controller can still aggregate/compress these L2P mapping entries on the L2P cache (usually DRAM) and save space in the L2P cache.
2. A fix for this issue has been committed to my latest pull request.
3. 2 represents the number of planes in each lun. Usually, pages within multiple planes in a chip need to be programmed in parallel. I have modified it to id_zns->planes_per_lun. Considering the lack of understanding of plane-level parallelism, this variable is currently unused.
4. LOGICAL_PAGE_SIZE indicates the host (or operating system) page size, which is typically 4 KiB. ZNS_PAGE_SIZE indicates the flash page size, which is typically 16 KiB. Both values are independent of the media type of the flash memory. The media type of the flash memory affects the programming unit, e.g. QLC requires four flash pages to be programmed at a time.

I got it. Thank you so much!