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

[acess]

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

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

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

[Rocketer]

你猜“主控”是什么？不就是个嵌入式的软件吗？

[acess]

刚刚在想，首先一个坏处是用户认知方面，容量不止一种给用户增加认知负担，容量看上去一下子少了三分之二或者四分之三之类也会带来困惑。

还有一件事，文件系统自身的元数据这样一来应该默认 SLC 化了，但这应该不是坏事我感觉，甚至应该是一件好事，因为这些数据，量不大占存储并不多，经常改动，而且要求更高的性能与可靠性……

[acess]

@Rocketer 主控跑着固件，固件当然也是软件咯……但我猜要实现我的想法大概还涉及底层的，那个叫界面规范还是叫通信协议呢，这方面都需要改吧可能，是标准要改了

[acess]

或者可以这么说，我的认知里本来 TLC/QLC 这样的技术为了牺牲就太大了，不是一个不经大脑考虑就应该采用的东西，也不是一个靠得住的东西：从初代 TLC 消费盘 840EVO 开始就有冷数据问题了，现在也不过是把问题重新定义为常态，还把定期读取检查重写这样的缓解/掩盖问题的手段美其名曰称为数据烘焙……这甚至可以算是对用户的一种欺瞒。

“真正的”容量本来就应该按照 SLC 来算的。

但是这些技术也有可取之处（很明显就是能存更多数据啊，而且读取也快只是写入慢），用户有足够认知就可以 opt-in ，然后自己负责，寻找最优的管理与利用方法。

而不是全部被主控固件屏蔽无法控制。

[acess]

嘛我的观点有点太激进了而且还漏打了几个字……

[acess]

刚刚还想到磁带外包装就是看上去很鸡贼，标了两种容量然后还把算法压缩的“虚”容量（很显然实际未必能压缩那么多甚至可能完全无法压缩）标到主要/醒目的位置……

TLC/QLC 至少是物理层面确定的能压到原先的三分之一或四分之一，从消费者考虑其实相比磁带那种标法都相对是良心的（ x

[ReactRails]

鉴定为民科，SLC 都死了八百年了还搁这儿念叨呢

[echo1937]

你可以把你的想法和 GPT 聊一聊，他会很耐心和你讨论，并且给你提供一些扩展信息。

[acess]

发帖前我还想到过像磨损平衡、纠错、坏块管理等等这些，还有其他很多事情是主控负责的。

其实像 jffs2 这样就是可以直接对接裸 flash 的。

但想想又觉得这些未必都需要交给操作系统/文件系统/主机管理……比如各厂的 flash 可能有一些特殊的 kink 需要特别照顾，可能还是主控负责比较合适。



还有一件事就是，可能以 TLC/QLC 标准看已经磨损到损坏无法继续写入使用的盘，其实换一个视角以 SLC 标准看那只是有些许（甚至还算是量并不多的）磨损。

那么如果按照“TLC/QLC 只是一种压缩”这种视角看，那一块盘的磨损耐久（ em 这个可能也未必等价于以时间计算的“寿命”）就大大延长了，磨损多了只是“不能再（可靠地）压缩了”，而不是“彻底坏了”。

[acess]

@ReactRails 如果不是从技术迭代发展角度去看，那很显然 SLC 并没有死，现在的消费级 SSD 默认都是开启 SLC cache 不是么，甚至全盘“模拟”SLC

[povsister]

你这个想法还挺“民科”的，TLC/QLC 读写就不需要软件参与了吗，何来“硬件压缩”之说
ssd 一大优势就是文件系统不用再考虑磁盘上文件的物理存储位置，这句话也不全对，其实是硬盘主控帮你做了。传统机械硬盘你可以理解为线性映射，文件系统还必须定期碎片整理优化才能保证持续读写性能。你这一想法直接技术倒退五十年

[acess]

可以说我们现在其实都还在用 SLC ，厂商宣传时跑分也是跑的 SLC 模式的读写速度。

[acess]

@povsister 纠结硬件/软件这几个字眼没意思

但确实，我自己后来都意识到，这个想法最 bug 最傻 x 的地方在于，“我有一个盘剩余空间 8G ，能不能装下 10G 的文件”——用户还得在大脑里折算一下，哦，10 除以 3 等于，多少来着，3.33 ？还除不尽，不过好像还是能装下的（ x

还有操作系统层面也要考虑，什么时候报错可用空间不足无法写入

乃至应用也要多一个写入模式……一切事情都变复杂了可能

再有就是可能有时候意外配错了，怎么写入那么慢，各种排错检查折腾了一圈，哦原来开了压缩，甚至可能因为应用代码里写死了用 TLC 模式写入所以用户毫无办法（ x

[acess]

@povsister “是用 TLC 还是 SLC 模式写入”这个当然在主控固件里也还是有一套算法来管理的……不过你确实可以吐槽说硬件/软件这两个相对的概念使用不妥

还有……现在一提到“压缩”通行的理解全都是指代算法实现的“数据压缩”，但我确实觉得 3 个 bit 挤进一个存储单元这种事情你叫他“物理压缩”好像问题也不大啊？“压缩”这个概念本来不就是从物理世界借用过来的嘛……

[yannxia]

从架构上整个计算机体系就是在不断地屏蔽实现以对上层提供接口，你说的其实没有问题，比如某大厂，发现这个可以提高性能之类的，就会有人去做，参考 ByKenerl 的技术蓬勃发展，现在没什么用的主要原因是没有太大的商业价值。

[acess]

@povsister 哦还有，我也没有隐含说比如主机指定 TLC 模式写进去，那个文件的物理存储位置就固定不准挪动了。只要 SLC 模式的写入多折算 3 倍（大概），都可以算进磨损平衡里一起搅和

[acess]

（嘛很显然还是不应该只折算 3 倍然后就搅和到一起磨损均衡了，TLC 模式对磨损比 SLC 敏感得多，如果不想太快就失去 TLC 模式写入的能力，那还需要特别处理，比如预留一部分空间不磨损……但相比闭着眼全盘 SLC cache 的现状我感觉至少不会更差吧）

[sujin190]

你是不是应该先了解下 ssd 的 bank cell 相关的概念，文件系统对 ssd 每 bit 并不能是随机的，并不能想读哪就读哪想写哪就写哪的好吧，如果是这样文件系统逻辑抽象和物理抽象两者并不能直接对应，那你想的这种文件系统逻辑压缩直接对应到 ssd 物理压缩根本实现不了好吧

[ferock]

根本实现不了

[fairytale]

确切的说，这个设计已经玩烂了了。交给设备主控处理兼容性好。有极致性能与成本需求的，直接 2 块 slc+20 块 qlc 完事，不会单盘做文章。有一种盘叫 HM-Smr ，可以用 f2fs ，它拆分了 bmr 区和 smr 区，并把 smr 区的 trim 和 gc 交给了操作系统来管理。还有一个东西叫傲腾+qlc 组合，交给操作系统的驱动(并不是 sshd ，实际是两块独立的设备)，来管理热数据与冷数据。