突发奇想，如果 SSD 把 MLC/TLC/QLC 等视为一种物理层面的“数据压缩”，暴露给文件系统管理会怎样？
acess · 53 天前 via Android · 2307 次点击这是一个创建于 53 天前的主题，其中的信息可能已经有所发展或是发生改变。
文件系统默认显示的是 SLC 模式容量。
可以像目前算法压缩那样去做文件级别的管理，压缩时可选“软件算法压缩”还是“硬件物理压缩”，可以对某个目录或整卷设置属性或者挂载选项配置是否启用。
印象里 TLC/QLC 直读速度也不差，只是写入慢，感觉很适合类似 CompactOS 那种只读用法。
31 条回复
 |
1
Rocketer 53 天前 via iPhone  1
你猜“主控”是什么？不就是个嵌入式的软件吗？
|
 |
2
acess OP 刚刚在想，首先一个坏处是用户认知方面，容量不止一种给用户增加认知负担，容量看上去一下子少了三分之二或者四分之三之类也会带来困惑。
还有一件事，文件系统自身的元数据这样一来应该默认 SLC 化了，但这应该不是坏事我感觉，甚至应该是一件好事，因为这些数据，量不大占存储并不多，经常改动，而且要求更高的性能与可靠性…… |
|
3
acess OP @Rocketer 主控跑着固件，固件当然也是软件咯……但我猜要实现我的想法大概还涉及底层的，那个叫界面规范还是叫通信协议呢，这方面都需要改吧可能，是标准要改了
|
|
4
acess OP 或者可以这么说，我的认知里本来 TLC/QLC 这样的技术为了牺牲就太大了，不是一个不经大脑考虑就应该采用的东西，也不是一个靠得住的东西：从初代 TLC 消费盘 840EVO 开始就有冷数据问题了，现在也不过是把问题重新定义为常态，还把定期读取检查重写这样的缓解/掩盖问题的手段美其名曰称为数据烘焙……这甚至可以算是对用户的一种欺瞒。
“真正的”容量本来就应该按照 SLC 来算的。 但是这些技术也有可取之处（很明显就是能存更多数据啊，而且读取也快只是写入慢），用户有足够认知就可以 opt-in ，然后自己负责，寻找最优的管理与利用方法。 而不是全部被主控固件屏蔽无法控制。 |
|
5
acess OP 嘛我的观点有点太激进了而且还漏打了几个字……
|
|
6
acess OP 刚刚还想到磁带外包装就是看上去很鸡贼，标了两种容量然后还把算法压缩的“虚”容量（很显然实际未必能压缩那么多甚至可能完全无法压缩）标到主要/醒目的位置……
TLC/QLC 至少是物理层面确定的能压到原先的三分之一或四分之一，从消费者考虑其实相比磁带那种标法都相对是良心的（ x |
 |
7
ReactRails 53 天前 via iPhone
鉴定为民科，SLC 都死了八百年了还搁这儿念叨呢
|
 |
8
echo1937 53 天前
你可以把你的想法和 GPT 聊一聊，他会很耐心和你讨论，并且给你提供一些扩展信息。
|
|
9
acess OP 发帖前我还想到过像磨损平衡、纠错、坏块管理等等这些，还有其他很多事情是主控负责的。
其实像 jffs2 这样就是可以直接对接裸 flash 的。 但想想又觉得这些未必都需要交给操作系统/文件系统/主机管理……比如各厂的 flash 可能有一些特殊的 kink 需要特别照顾，可能还是主控负责比较合适。 还有一件事就是，可能以 TLC/QLC 标准看已经磨损到损坏无法继续写入使用的盘，其实换一个视角以 SLC 标准看那只是有些许（甚至还算是量并不多的）磨损。 那么如果按照“TLC/QLC 只是一种压缩”这种视角看，那一块盘的磨损耐久（ em 这个可能也未必等价于以时间计算的“寿命”）就大大延长了，磨损多了只是“不能再（可靠地）压缩了”，而不是“彻底坏了”。 |
|
10
acess OP @ReactRails 如果不是从技术迭代发展角度去看，那很显然 SLC 并没有死，现在的消费级 SSD 默认都是开启 SLC cache 不是么，甚至全盘“模拟”SLC
|
 |
11
povsister 52 天前 via iPhone 1
你这个想法还挺“民科”的，TLC/QLC 读写就不需要软件参与了吗，何来“硬件压缩”之说
ssd 一大优势就是文件系统不用再考虑磁盘上文件的物理存储位置，这句话也不全对，其实是硬盘主控帮你做了。传统机械硬盘你可以理解为线性映射，文件系统还必须定期碎片整理优化才能保证持续读写性能。你这一想法直接技术倒退五十年 |
|
12
acess OP 可以说我们现在其实都还在用 SLC ，厂商宣传时跑分也是跑的 SLC 模式的读写速度。
|
|
13
acess OP @povsister 纠结硬件/软件这几个字眼没意思
但确实，我自己后来都意识到，这个想法最 bug 最傻 x 的地方在于，“我有一个盘剩余空间 8G ，能不能装下 10G 的文件”——用户还得在大脑里折算一下，哦，10 除以 3 等于，多少来着，3.33 ？还除不尽，不过好像还是能装下的（ x 还有操作系统层面也要考虑，什么时候报错可用空间不足无法写入 乃至应用也要多一个写入模式……一切事情都变复杂了可能 再有就是可能有时候意外配错了，怎么写入那么慢，各种排错检查折腾了一圈，哦原来开了压缩，甚至可能因为应用代码里写死了用 TLC 模式写入所以用户毫无办法（ x |
|
14
acess OP @povsister “是用 TLC 还是 SLC 模式写入”这个当然在主控固件里也还是有一套算法来管理的……不过你确实可以吐槽说硬件/软件这两个相对的概念使用不妥
还有……现在一提到“压缩”通行的理解全都是指代算法实现的“数据压缩”，但我确实觉得 3 个 bit 挤进一个存储单元这种事情你叫他“物理压缩”好像问题也不大啊？“压缩”这个概念本来不就是从物理世界借用过来的嘛…… |
 |
15
yannxia 52 天前 3
从架构上整个计算机体系就是在不断地屏蔽实现以对上层提供接口，你说的其实没有问题，比如某大厂，发现这个可以提高性能之类的，就会有人去做，参考 ByKenerl 的技术蓬勃发展，现在没什么用的主要原因是没有太大的商业价值。
|
|
16
acess OP @povsister 哦还有，我也没有隐含说比如主机指定 TLC 模式写进去，那个文件的物理存储位置就固定不准挪动了。只要 SLC 模式的写入多折算 3 倍（大概），都可以算进磨损平衡里一起搅和
|
|
17
acess OP （嘛很显然还是不应该只折算 3 倍然后就搅和到一起磨损均衡了，TLC 模式对磨损比 SLC 敏感得多，如果不想太快就失去 TLC 模式写入的能力，那还需要特别处理，比如预留一部分空间不磨损……但相比闭着眼全盘 SLC cache 的现状我感觉至少不会更差吧）
|
 |
18
sujin190 52 天前 via Android
你是不是应该先了解下 ssd 的 bank cell 相关的概念，文件系统对 ssd 每 bit 并不能是随机的，并不能想读哪就读哪想写哪就写哪的好吧，如果是这样文件系统逻辑抽象和物理抽象两者并不能直接对应，那你想的这种文件系统逻辑压缩直接对应到 ssd 物理压缩根本实现不了好吧
|
 |
19
ferock 52 天前 via iPhone
根本实现不了
|
 |
20
fairytale 52 天前 via Android
确切的说，这个设计已经玩烂了了。交给设备主控处理兼容性好。有极致性能与成本需求的，直接 2 块 slc+20 块 qlc 完事，不会单盘做文章。有一种盘叫 HM-Smr ，可以用 f2fs ，它拆分了 bmr 区和 smr 区，并把 smr 区的 trim 和 gc 交给了操作系统来管理。还有一个东西叫傲腾+qlc 组合，交给操作系统的驱动(并不是 sshd ，实际是两块独立的设备)，来管理热数据与冷数据。
|
|
21
fairytale 52 天前 via Android 1
企业盘的 qlc 都是直写，根本不搞 slc cache
|
|
22
acess OP @sujin190 我好像不太明白你说的“每 bit 随机”是什么意思，据我所知虽然闪存的擦除和写入最小单元不一样但都是基于 block 的，好像只有傲腾 DCPMM 才能按字节寻址。
但看你的回复，我想了想，突然意识到我都忘了现有体系下一个设备内部的块大小是固定一致的不会忽大忽小，比如请求读一个 LBA 就只会返回 512 字节；不会请求读这个地址返回 512 字节，下一个地址就返回 1536 字节了，甚至从来没人想到过考虑过未来会出现这种状况。 （嘛我记得也有设备不是 512 而是 4096 ，528 等等其他数字，但一个设备还是只有一个固定的数值） 然后，想要实现我的想法需要在接口协议层面引入新的 TLC 模式读写命令。 于是，这种“压缩”的兼容性就基本完蛋了…… 同一块盘插到老系统上，会各种报错： 首先是文件系统驱动发现自己不认识新的“压缩方式”； 其次就算某个文件系统实现无视这一点试图强行去读，因为接口协议层面引入了新的 TLC 模式读取命令，主控那边发现主机没有按照新命令读取，拒绝返回数据。 某种程度上可以聊以自慰的是，写入的时候，如果还是用老的写入命令，那应该可以不报错，所以（呃还得假设格式化程序不会先读取检查什么再写）如果在老系统上格式化了，那格式化还是可以正常完成，会变成一块纯 SLC 的盘。 除此之外不用多说，现有的各种直接读 block 的实用工具，像 DiskGenius 一样做数据恢复和备份的软件，也会全部挂掉…… （乐观估计的话，也许没设为压缩的文件在老系统上说不定还能读，逃） |
|
23
acess OP @fairytale HM-SMR 和 F2FS 本来我也想提但搜了一下发现我有一点记错了所以没提，f2fs 我误以为是直接对接裸设备的（而且还是跟既存系统不兼容不能吃不能碰、一碰就报错吓你一跳的裸设备），但搜了一下看到说闪存上它不是这样。
然后我想确实如你所说，如果作为用户真的想要掌控这些技术细节，那么选企业级产品就好，企业 QLC 盘就不搞 SLC cache ，SLC 就是 SLC （比如听起来高大上的 SCM XL-Flash ） QLC 就是 QLC ，然后上层怎么搞都可以随心所欲了。 |
|
24
acess OP 嘛算了，我点下沉了
|
 |
25
Rorysky 52 天前
你说的部分实现了，
现在 ssd 的缓存区域就是用的 slc 模拟，其他数据区域都是 三层 tlc ， 这部分你还原成 slc 没有用处呀 |
 |
26
Admstor 52 天前
文件管理系统只想说，别来沾边
现在纠错算法还是蛮吃算力，硬盘主控都是特意定制的，你暴露给操作系统还要占用 CPU ，这是何必 另外操作系统是要给普通人用的，你确定普通用户可以理解？随便一个操作资料没了，你猜用户是骂微软还是骂存储厂家 |
 |
27
txhwind 52 天前
类似于把主控做进硬盘驱动里？我感觉现在主要问题是生产工艺经常变，不好给软件暴露统一接口，放在主控固件里比较方便保证兼容性。
|
 |
28
shijingshijing 52 天前
我比大厂更 nb 系列
|
 |
29
kkocdko 52 天前
我认为你的想法很有趣，很有价值。虽然实现起来工作量比较大。
请不要理会楼上某些不懂装懂还嘲讽你的傻子。 我有另外一种想法，也许可以更好地实现你的目的。 目前的 TLC/QLC NAND 大多数都可以在开卡/量产的时候调整 SLC 模式的激进程度。我认为，在不更改当前的文件系统体系的情况下，可以使用两块盘/两个存储池，一块盘在硬件上使用纯 SLC 模式，另一块使用纯 QLC 模式，然后使用 bcache/lvm cache 来实现软件精确控制缓存策略的目的。 |
|
30
kkocdko 52 天前
我完全同意 @yannxia 的观点，楼主的标题可能比较有误导性，但这种将上层 offload 到下层，或者让下层被上层感知，或者下层 bypass 上层的做法，只要有利可图，就会有人去做。
|
 |
31
tsohgdivil 50 天前
我只能说你说的这种难度不在于技术上
|
Select Language