突发奇想，如果 SSD 把 MLC/TLC/QLC 等视为一种物理层面的“数据压缩”，暴露给文件系统管理会怎样？

[acess]

文件系统默认显示的是 SLC 模式容量。

可以像目前算法压缩那样去做文件级别的管理，压缩时可选“软件算法压缩”还是“硬件物理压缩”，可以对某个目录或整卷设置属性或者挂载选项配置是否启用。

印象里 TLC/QLC 直读速度也不差，只是写入慢，感觉很适合类似 CompactOS 那种只读用法。

[fairytale]

企业盘的 qlc 都是直写，根本不搞 slc cache

[acess]

@sujin190 我好像不太明白你说的“每 bit 随机”是什么意思，据我所知虽然闪存的擦除和写入最小单元不一样但都是基于 block 的，好像只有傲腾 DCPMM 才能按字节寻址。

但看你的回复，我想了想，突然意识到我都忘了现有体系下一个设备内部的块大小是固定一致的不会忽大忽小，比如请求读一个 LBA 就只会返回 512 字节；不会请求读这个地址返回 512 字节，下一个地址就返回 1536 字节了，甚至从来没人想到过考虑过未来会出现这种状况。

（嘛我记得也有设备不是 512 而是 4096 ，528 等等其他数字，但一个设备还是只有一个固定的数值）

然后，想要实现我的想法需要在接口协议层面引入新的 TLC 模式读写命令。

于是，这种“压缩”的兼容性就基本完蛋了……

同一块盘插到老系统上，会各种报错：

首先是文件系统驱动发现自己不认识新的“压缩方式”；

其次就算某个文件系统实现无视这一点试图强行去读，因为接口协议层面引入了新的 TLC 模式读取命令，主控那边发现主机没有按照新命令读取，拒绝返回数据。

某种程度上可以聊以自慰的是，写入的时候，如果还是用老的写入命令，那应该可以不报错，所以（呃还得假设格式化程序不会先读取检查什么再写）如果在老系统上格式化了，那格式化还是可以正常完成，会变成一块纯 SLC 的盘。

除此之外不用多说，现有的各种直接读 block 的实用工具，像 DiskGenius 一样做数据恢复和备份的软件，也会全部挂掉……

（乐观估计的话，也许没设为压缩的文件在老系统上说不定还能读，逃）

[acess]

@fairytale HM-SMR 和 F2FS 本来我也想提但搜了一下发现我有一点记错了所以没提，f2fs 我误以为是直接对接裸设备的（而且还是跟既存系统不兼容不能吃不能碰、一碰就报错吓你一跳的裸设备），但搜了一下看到说闪存上它不是这样。

然后我想确实如你所说，如果作为用户真的想要掌控这些技术细节，那么选企业级产品就好，企业 QLC 盘就不搞 SLC cache ，SLC 就是 SLC （比如听起来高大上的 SCM XL-Flash ） QLC 就是 QLC ，然后上层怎么搞都可以随心所欲了。

[acess]

嘛算了，我点下沉了

[Rorysky]

你说的部分实现了，

现在 ssd 的缓存区域就是用的 slc 模拟，其他数据区域都是 三层 tlc ， 这部分你还原成 slc 没有用处呀

[Admstor]

文件管理系统只想说，别来沾边

现在纠错算法还是蛮吃算力，硬盘主控都是特意定制的，你暴露给操作系统还要占用 CPU ，这是何必

另外操作系统是要给普通人用的，你确定普通用户可以理解？随便一个操作资料没了，你猜用户是骂微软还是骂存储厂家

[txhwind]

类似于把主控做进硬盘驱动里？我感觉现在主要问题是生产工艺经常变，不好给软件暴露统一接口，放在主控固件里比较方便保证兼容性。

[shijingshijing]

我比大厂更 nb 系列

[kkocdko]

我认为你的想法很有趣，很有价值。虽然实现起来工作量比较大。

请不要理会楼上某些不懂装懂还嘲讽你的傻子。

我有另外一种想法，也许可以更好地实现你的目的。

目前的 TLC/QLC NAND 大多数都可以在开卡/量产的时候调整 SLC 模式的激进程度。我认为，在不更改当前的文件系统体系的情况下，可以使用两块盘/两个存储池，一块盘在硬件上使用纯 SLC 模式，另一块使用纯 QLC 模式，然后使用 bcache/lvm cache 来实现软件精确控制缓存策略的目的。

[kkocdko]

我完全同意 @yannxia 的观点，楼主的标题可能比较有误导性，但这种将上层 offload 到下层，或者让下层被上层感知，或者下层 bypass 上层的做法，只要有利可图，就会有人去做。

[tsohgdivil]

我只能说你说的这种难度不在于技术上