关于闪存FTL的Host Base和Device Based的误解
关于SSD关于HostBase和DeviceBased的误解...
此文写作过程中得到了ssdfans群友的帮助，在此表示感谢！
关于Device Based与Host Based
Device Based就是一切FTL处理全由SSD主控负责，包括磨损均衡、地址映射等。这也是常规的做法。还有一类Host based，所有的FTL处理全部交给主机端的模块，或内核态或用户态。此时，主机端运行的FTL模块就要在综合评判均衡之后对页面写入做重定向操作，并负责更新保存在主机端RAM中的大映射表，同时，也仍然需要将逻辑页号保存到页面中一同存储。这样，就算主机端掉电，也还是可以从所有page中抽取逻辑页号重构映射表。这里有个认知误区，不少人认为，主机端只更新内存中的大映射表，于是便有了个疑问：映射表如此大，更新之后如果主机一旦掉电，岂不是就丢掉了，所以是不是每一笔映射关系的更新都要同步到后端的Flash中？如果这样性能将会变差。
所以，不管是Device Based还是Host Based，这张大映射表都要被存储到RAM中，前者存储在SSD自己的RAM，后者存储在Host的RAM，但是它俩都需要将逻辑页号随着有效内容一同写入Flash Page。FTL映射表很大，SSD上没有这么大的电容量在掉电后把整个表都拷贝回Flash。
有些早期产品在掉电之后甚至需要半个多小时来重建映射表，比如一些大容量PCIE SSD，没有重构完的话就不能接受IO，所以其必须在BIOS扫描PCIE设备的时候通过optional rom加载个驱动，这个驱动与PCIE SSD通信从而获知其重构进度，并将BIOS暂停在某个页面上，直到重构完成，整个系统继续启动。
而最新的产品中也并没有电量大到能够将数百兆上GB的表拷贝到Flash的大电容。目前的解决办法都是将这张大表里的脏页面在后台不断的刷入Flash。比如，可以采用SLC Flash来保存这个大表，加快写入速度，同时保证有足够的寿命。或者在MLC/TLC FLash上开辟一片专区，以SLC的方式对其Program，也就是直接将其充电到最大程度，而不需要充电到某个区间，这样也能够加快速度。
对于那些没来得及写入Flash的表，如果是Device Based的，掉电后可以依靠SSD内的电容，将脏页面在几十ms时间内迅速写入Flash。比如，可以对脏页面保存一个bitmap，凡是脏的，bitmap中对应偏移量被置1，掉电后在电容的电力下，代码迅速扫描bitmap将脏页刷Flash，几十ms对人脑来讲那就是一瞬，但是对CPU来讲，确可以做不少事情。
对于Host Based的SSD，掉电后没来得及下盘的脏页被丢掉，重启之后，只需要将这些丢掉的表页面从Flash Page中重构出来即可，所以，掉电之前，系统必须保证将 “有哪些脏页上次没有刷入” 的信息保存到Flash，比如如果用了bitmap追踪的话，那么每一笔对映射表的更新都需要同步刷入bitmap，假设500MB的FTL表，如果每个bit描述表中的4K内存页面的话，bitmap一共也就15KB左右。掉电后，主机端FTL代码从Flash将bitmap读出，扫描，重构。
或者采用日志方式，就像数据库那样，每一笔对映射表的更新都记录下日志，该日志同步刷入Flash，掉电后，读出日志做redo。
如何知道系统掉电？PCIE设备在系统掉电之后会收到一个中断信号，内部的CPU可以利用这几十ms的时间打扫战场。有人可能有疑问，掉电了还能收到信号？电源内的电容一般会在掉电之后保存有能够让整个系统再撑10ms左右的电量，电源一旦发现掉电，立即发送信号到主板芯片组，此时芯片组会发出一系列中断，包括给CPU，以及PCIE设备，CPU此时立即将cache flush到ram，这一步其实没用，因为ram照样掉电，但是如果用的是NVRAM/NVDIMM，就不一样了。但是，如果是SATA SSD，其无法直接收到掉电信号，但是系统桥上SATA控制器是可以的，SATA控制器收到掉电信号之后也会打扫战场，将没来得及写入SSD的数据写入之后便等待断电了，而SATA SSD此时只能靠自己了，也就是靠自身电容最最后打扫战场的工作。
其他相关阅读：
《【冬瓜哥画PPT】浅谈闪存控制器架构》《【冬瓜哥论文】浅析固态介质在存储系统中的应用方式》
《你绝对想不到的两种高逼格存储器》
《【冬瓜哥手绘】大话众核心处理器体系结构》
《关于SSD元数据及掉电保护的误解》
关注 大话存储
微信扫一扫关注公众号
