毁三观？你所不知道的那些SSD的事 • 三

l48463628 · 发表于 2014-8-12 12:09

定个Q以后慢慢看

灰之影 · 发表于 2014-8-13 21:06

小白问一下，4k性能在日常应用究竟体现在哪些方面呢？

nighttob · 发表于 2014-8-13 22:11

灰之影发表于 2014-8-13 21:06
小白问一下，4k性能在日常应用究竟体现在哪些方面呢？

系统载入，软件安装，软件载入

keysis · 发表于 2014-8-14 09:40

支持，很好的东西啊，赞一个

ysydys · 发表于 2014-8-14 19:41

虽然看不明白，但是感觉好厉害的样子

haierccc · 发表于 2014-8-15 20:47

纯技术好文！

Sayhoo · 发表于 2014-8-15 21:38

这是否说明这2年出的SSD提升的性能其实都没太大的实用意义还不如降价来得明显些？

讯极天度 · 发表于 2014-8-17 14:51

颇为受益！多谢楼主。后面几句话有点意思

panderul · 发表于 2014-8-29 17:17

一下午都在充电补脑了，

coolerlan · 发表于 2014-11-16 12:43

哈哈哈看到最后的吐槽好欢乐

xia86101 · 发表于 2014-11-18 11:50

SF 还是相对来说低端了一些，基本上深圳这边的小厂都可以拿到方案，跟SMI 一样，JMF相对来说，就高端一些，价位和严格程度都不是SF能比的。

szyzb · 发表于 2014-11-22 10:18

观点鲜明，好。

rgwan · 发表于 2016-3-21 20:13

一般DRAM不会完全放下整个映射表，比如说128G NAND，16K page算，就要32MB空间。大多数基于B+ tree/DFTL/hybird mapping的算法要么靠展开树+superblock，要么靠缓存算法，要么靠页表+块表混合用。不过我看的资料包括我自己实现的FTL都较为老旧（4年前），不知现在还是否流行压缩映射表的做法。

nighttob · 发表于 2016-3-21 20:32

rgwan 发表于 2016-3-21 20:13
一般DRAM不会完全放下整个映射表，比如说128G NAND，16K page算，就要32MB空间。大多数基于B+ tree/DFTL/hy ...

page mapping或者其他平面映射表在现在消费级还是主流，企业级上会有其他算法
如果闪存容量继续翻倍增长，但主控MC没有进步的话，FTL肯定要换个思路去做了

2012年以前像B-tree这种算法确实很流行，但似乎一瞬间就全变page mapping了，除了SF以外

rgwan · 发表于 2016-3-21 21:52

nighttob 发表于 2016-3-21 20:32
page mapping或者其他平面映射表在现在消费级还是主流，企业级上会有其他算法
如果闪存容量继续翻倍增长 ...

以前三星在小型设备上的设计大多是用混合映射——块表+页表。只需要非常少的内存就能管理较大的NAND Flash，U盘主控也大多是这么做的。我半年来的工作大概就是让NAND适配微型设备，大概我论文发了那个小FTL就能开源了。

SSD控制器就不太清楚了，如果用DFTL算法的话，维护个比较大的页映射表对内存要求是高一些，而且要快速启动只能依靠超级块，读取性能上混合映射稍微好一些，随机写入上DFTL/WA-DFTL好一些。

B+树/u树我觉得在性能上和内存占用做的会比页映射好一些，时间复杂度也可以，我也打算结合DFTL和u树做我的项目。不过目前我的研究方向主要在保证实时性，稳定性，性能对我倒是次要的。B+/u树这点要好一些，不太依赖超级块。

rgwan · 发表于 2016-3-21 21:58

本帖最后由 rgwan 于 2016-3-21 22:07 编辑

nighttob 发表于 2016-3-21 20:32
page mapping或者其他平面映射表在现在消费级还是主流，企业级上会有其他算法
如果闪存容量继续翻倍增长 ...

其实我个人是不喜欢FTL这种东西的，在操作系统的文件系统层面直接使用类似UBIFS/NANDFS之类的NAND专用文件系统，SSD主控做好纠错和坏块屏蔽就可以了。这样可以杜绝不少隔靴搔痒的机制，比如TRIM和SE。文件系统的优化也会更显而易见，比如说零散写入完全可以由文件系统合并请求，直接适配到NAND的块或者页大小，可以显著降低写放大。掉电也不会导致掉盘问题——起码系统还能启动，在fsck这段时间里起码用户可控的部分更多，而不是插个电等30分钟后看人品。当然，也变相的降低了SSD厂商的门槛~何乐而不为。当然，用户可控的参数也能更多，比如说可以直观的调查文件系统的效率，更有效率以ECC错误率估测寿命，甚至寿命快到了的时候，在卷未满时自动减小容量使用SLC模式续命等等。这么做后Flash的存储弹性更高，稳健性应当更好。现在看很多消费级SSD寿命一到就直接挂机认不到盘，简直……如果我做FTL的话只要ECC错误到达阈值，全盘只读。做FlashFS到ECC阈值，报警+SLC续命，再到阈值，只读报警~

nighttob · 发表于 2016-3-21 22:21

rgwan 发表于 2016-3-21 21:58
其实我个人是不喜欢FTL这种东西的，在操作系统的文件系统层面直接使用类似UBIFS/NANDFS之类的NAND专用文件 ...

所以我说这是消费级的策略，企业级可以做到聪明且周全，但这都是成本

光一个4k对齐就已经让成堆的人茫然不知所措了，再来个专用文件系统就是99% GG了

rgwan · 发表于 2016-3-21 22:56

nighttob 发表于 2016-3-21 22:21
所以我说这是消费级的策略，企业级可以做到聪明且周全，但这都是成本

光一个4k对齐就已经让成堆的人茫然 ...

现在消费级的盘直接写到爆表的机制我觉得太暴力了。如果到达了认为寿命该终止的时候，应该给用户一个挽救数据的机会，即使是立刻写保护。

nighttob · 发表于 2016-3-22 07:03

rgwan 发表于 2016-3-21 22:56
现在消费级的盘直接写到爆表的机制我觉得太暴力了。如果到达了认为寿命该终止的时候，应该给用户一个挽救 ...

有厂家这么做，但不是全部

frontwing · 发表于 2016-3-22 07:53

rgwan 发表于 2016-3-21 22:56
现在消费级的盘直接写到爆表的机制我觉得太暴力了。如果到达了认为寿命该终止的时候，应该给用户一个挽救 ...

理论上在SMART定义里弄一个统一标准的MWI值，让windows根据它发出预警（而不是不知所云的蓝屏）就可以了，就看愿不愿意做。