地 址：湖南长沙高新区麓云路100号兴工国际产业园10栋301
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 ，所以其必须在Bioses扫描PCIE设备的时候通过optional rom加载个驱动 ，这个驱动与PCIE SSD通信从而获知其重构进度 ，并将Bioses暂停在某个页面上 ，直到重构完成，整个系统继续启动。
而最新的产品中也并没有电量大到能够将数百兆上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此时只能靠自己了，也就是靠自身电容最最后打扫战场的工作。