一般来说，传统的SSD架构是下面这个样子滴。
向上通过PCIe/NVMe跟Host沟通，向下通过Toggle/ONFI跟Flash沟通，剩下所有的事情都交给ASIC和FW。
CNEXLab认为可以有更好的安排，那就是Open Channel：
其核心就是把原本由FW处理的一部分工作，交给Host这边的Driver（LightNVM）来做：
- Data Placement: Host直接对Physical Page进行操作，
- I/O Scheduling：
- Background Operation：Host负责Background Operation
把FTL的核心功能LPA<->PBA映射交给Host负责，Host直接对Physical Page进行操作，同时负责IO的分发以及决定何时进行Background Operation(比如GC)。
这样做的好处：
- 根据Host端应用场景的情况来动态调整GC的策略，从而提供更好的用户体验， 比如蛋蛋看高清小电影的时候，暂停GC让播放不要卡顿，等蛋蛋暂停去吃饭了再进行GC；
- 针对特定的数据Pattern写入，通过合理摆放避免影响旁边page的数据；
- 尽可能多的物理页并行读写；
- 更高效地使用Host的CPU/Memory资源；
- SSD主控work loading降低，可以使用更低的主频和更小的Memory，降低功耗和成本；
- 对于特定的Pattern，通过Host端提前优化可以降低WA；
- FTL与文件系统或者应用软件深度融合；
那么，Host是如何实现直接对Physical Page读写的呢?
答案是使用NVMe Vendor Specific Command:
- Read PPA: “Read a PPA, in unit of a sector”
- Write PPA: “Write to a PPA, in unit of a sector”
- Erase PPA：”Erase an NVMe block”
- Identify Geometry: “Get geometry of device & media”
Physical Page地址格式如下：
- CHN：Channel Number
- PDU: PPA Data Unit number
- PLN: Plane Number
- LUN: Logical Unit Number
- FPG: Flash Page number
- BLK: Block number, erase block number in a plane
为了更加高效的统筹安排IO，Host FTL会维护一张类似Bitmap，从而优化下发IO时的物理地址。
使用Open-Channel SSD, host FTL可以针对不同的workload和应用进行优化，对存放在Flash里数据进行合理归集，从而可以降低OP，WA以及更高效的GC。
从而避免在SSD从全新到稳定状态后，Performance的断崖式下跌。
CNEXLab提供4种FTL的选择
- 传统模式—跟其他家一样
- CNEX “Optimized” Host FTL — 增加NVMe Vendor Specific command for Physical Page access
- LightNVM Host FTL – 增加Linux Kernel （Inbox Driver）Support
- LightNVM liblightnvm — 增加 “Get/Put” 命令支持
理想形态是下面这个样子，透过File 实验室tem， 块设备驱动，SSD主控，由应用直接下发数据到指定Physical Page。
