V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
iConnect
V2EX  ›  问与答

SSD 硬盘一般都预留 7%的空间作为冗余,是不是冗余坏完了,硬盘才报废?

  •  
  •   iConnect · 2017-11-23 23:09:28 +08:00 via Android · 7009 次点击
    这是一个创建于 2345 天前的主题,其中的信息可能已经有所发展或是发生改变。
    比如 256G 的 SSD,实际标注的可用空间是 240G。预留了 7%左右(各品牌预留比例有差异)的冗余空间。

    这个冗余空间的意思很明显,是为读写空间错误准备的。一块 SSD 坏掉,是不是冗余空间全坏光了?
    27 条回复    2017-11-24 13:12:20 +08:00
    tyhunter
        1
    tyhunter  
       2017-11-23 23:25:45 +08:00
    233333 难道这空间差异不是厂商和系统计算方式不同吗
    硬盘厂商是按照 1000 进制算的,那么 256G 是等于 1000*1000*256
    系统是按照 1024 进制算的,那么厂商的 256G 在系统眼里等于 1000*1000*256/( 1024*1024 )=244.140625GB
    goodan
        2
    goodan  
       2017-11-23 23:28:14 +08:00 via iPhone   ❤️ 2
    lz 思路有意思
    azh7138m
        3
    azh7138m  
       2017-11-23 23:29:59 +08:00
    @tyhunter 是预留了,不是因为 GiB 与 GB 的这种区别
    Icezers
        4
    Icezers  
       2017-11-23 23:48:08 +08:00 via iPhone   ❤️ 1
    的确有冗余 但是坏掉不一定是因为冗余用完了,大部分 SSD 挂掉是因为主控芯片
    flynaj
        5
    flynaj  
       2017-11-24 02:09:09 +08:00 via Android
    确实有很多 SSD 是 120g 跟 240g 的并不是
    128 跟 256,主控不同,价格有区别
    DiamondbacK
        6
    DiamondbacK  
       2017-11-24 03:37:39 +08:00
    @tyhunter
    GiB 和 GB 的区别与 SSD 预留空间( OP )是两回事。
    OP = Over-Provisioning
    OP 的大小因厂商、品牌、型号不同而不同,最小为 0,大的见过 50% 的,比如 256GB 的闪存用在 128GB 型号上。
    xupefei
        7
    xupefei  
       2017-11-24 04:30:34 +08:00
    不同品牌的 SSD 预留空间也不同。有些可以通过 SMART 查到具体剩下几块,有些只能查到剩余百分比:
    crazycen
        8
    crazycen  
       2017-11-24 07:58:03 +08:00 via iPhone
    @tyhunter 这个和单位换算没有关系,企业 ssd op 预留空间更是高达 30%
    mm163
        9
    mm163  
       2017-11-24 08:30:23 +08:00
    要想寿命长点儿,自己使用中要始终留出 1/4 ~ 1/3 以上的空间来。
    kokutou
        10
    kokutou  
       2017-11-24 08:33:47 +08:00 via Android
    @tyhunter
    ssd 是真的预留了,机械硬盘才是换算问题。
    md5
        11
    md5  
       2017-11-24 08:43:42 +08:00 via Android
    @kokutou ssd 标称容量是换算过的 还是 预留过的?
    runntuu
        12
    runntuu  
       2017-11-24 08:59:56 +08:00 via iPhone
    由于 ssd 只能对干净块执行写入,ssd 使用垃圾回收机制来对脏块进行回收合并。
    当 ssd 被填满后,就必须等待垃圾回收将脏块回收,这需要几个毫秒,而一般写是微秒级别,这会导致 ssd 性能严重下降。所以 ssd 一般会预留一部分空间来始终保证有干净块可写。
    twistedmeadows
        13
    twistedmeadows  
       2017-11-24 09:06:27 +08:00 via Android   ❤️ 11
    业内人士现身说法。

    是有预留的。但是不知道你这算法怎么来的。不是你这样算的。
    首先是 NAND Flash 厂商供应的闪存颗粒就有预留——每个 page 提供给用户的大小是 16KB,然而实际上有 18KB 左右的物理空间可用。
    然后就是 ssd 厂商预留用来做坏块替换的 block。这部分跟你讲的大致差不多。
    所以实际上如果你看到的硬盘有 240G,它物理上应该可以写 270G 甚至更多吧。

    跟二进制十进制换算没关系。但是厂商喜欢拿十进制换算来说事,假装这是历史遗留问题。消费者那边好解释一些。

    在坏块替换这个部分,各家的管理策略不一样。
    ssd 里面用 NAND Flash 组了阵列,全部并行做读写操作,这是 ssd 速度快的一个原因。
    如果一块 ssd 有 8ch 4ce 2plane,那就等于是 8*4*2=64 个 plane 在并行工作。不妨把 plane 理解为跑道,有 64 个跑道一起在为你发车。

    假如按你的 7%预留来考虑。其实质上是给每个 plane 都留了 7%的 block 用来做坏块替换。
    但如果有某个 plane 擦写次数特别多,导致很快就把 7%用完了呢?那它就不能跟其他 plane 一起做并行了。在有些厂商那里(实际上我认为大多数厂商都是吧),这块 ssd 就被认为寿命到头了,firmware 会将它设为 read only,只允许 host 从里面读取数据,做一点最后的抢救。

    至于为什么跑道少了一根就牵连所有跑道,这涉及 firmware 管理的问题。当然是受制于主控啊、DRAM 啊那些。不能把 firmware 写得太复杂。

    firmware 写得好的厂商,能确保均匀使用各个 plane。到最后寿命将近的时候,所有 plane 几乎会一起坏掉。
    twistedmeadows
        14
    twistedmeadows  
       2017-11-24 09:08:09 +08:00 via Android
    另外,SMART 查到的信息是没有参考价值的。host 发查询指令的时候,我们 ssd 这边的 firmware 想给它回什么值就回什么值。
    kokutou
        15
    kokutou  
       2017-11-24 09:29:41 +08:00   ❤️ 1
    @md5 #11
    预留后再换算。。。

    SSD 还有点特殊就是,例如有的时候用的实际物理颗粒容量是比 128 大这种,多的做 op,然后包装上的就是 128G
    实际物理就只有 128 的话,那包装上的可能就是 120G 这样。
    最后再 128 和 120 换算一下。。。

    也没有说包装上是 128G 的就很良心,因为它也可以 OP 设很小,只是让数字很漂亮而已,但是稳定就差了。
    不同主控,不同厂家,同厂家不同产品具体怎么做的都有可能不一样。。。
    mentalkiller
        16
    mentalkiller  
       2017-11-24 09:38:12 +08:00
    @twistedmeadows #13 感谢大佬分享知识,受益良多
    tyhunter
        17
    tyhunter  
       2017-11-24 10:30:01 +08:00
    @crazycen
    @azh7138m
    @DiamondbacK
    新知识 Get
    autoxbc
        18
    autoxbc  
       2017-11-24 10:44:33 +08:00 via iPhone
    注意买 mlc,平均寿命长的设备,在低区间的故障率也低,这是 tlc 比不了的
    imcxy
        19
    imcxy  
       2017-11-24 10:50:42 +08:00
    @autoxbc 现在 MLC 很少了吧,现在还是买个大容量靠谱,寿命跟容量也有关系
    honeycomb
        20
    honeycomb  
       2017-11-24 11:09:05 +08:00
    差不多就是这么回事

    @twistedmeadows
    楼主说的是 SSD 出厂时的默认 over provision(用来替换 block 的),不是说闪存上每个 page 单元的预留部分

    消费级别的往往是 7%(480GB 的实际上用了 512GB 的 die),企业级的比较喜欢用 21%(400GB/512GB)
    honeycomb
        21
    honeycomb  
       2017-11-24 11:11:25 +08:00
    这个 over provision 主要是用来帮助减小写入放大系数的(有越大的垃圾回收空间,写入放大系数越小),同时也能移植因空闲块数量变少导致的性能下降(空闲块的比例下限不会比 OP 的百分比更低)
    iyg429
        22
    iyg429  
       2017-11-24 11:58:04 +08:00 via iPhone
    @Icezers 其实 大部分坏的 ssd 都是主控问题。本身的 nand 颗粒还是好的。所以才会有回收旧 ssd。拆片重新开卡买的 很高利润。
    twistedmeadows
        23
    twistedmeadows  
       2017-11-24 12:11:54 +08:00 via Android
    @honeycomb 这位兄弟也是业内的?
    我是做后端的,所以对 NAND 这块比较熟。不知道你有没有手算过容量,即使按每个 page 16KB 来算,一个 64GB 的 die 也不止 64G 的可用容量。
    具体数据我就不摆了,因为不清楚哪些算机密。

    OP 留多大,我觉得是非常 various 的。
    跟 firmware 管理机制、NAND 厂商提供的 extended blocks 数量、面向的客户都有关。
    有些企业级客户会直接要求 OP 的大小。消费级也并不是固定 7%
    twistedmeadows
        24
    twistedmeadows  
       2017-11-24 12:13:17 +08:00 via Android
    @iyg429 有证据吗?哪家的主控?

    我觉得还是 NAND 寿命对 ssd 寿命影响大点。
    honeycomb
        25
    honeycomb  
       2017-11-24 12:22:24 +08:00 via Android
    @twistedmeadows
    是业内的话也会像你一样能手算容量啦

    我前面说的注释“用来替换 block 的”不对

    消费级 op 具体多少如你所说并不是固定,只是有些数字很容易猜。
    比如 128G 的比较像没留 op,120G 的比较可能是 7%,100G 的企业级产品比较像 21%,英特尔的 optane/三星的 slc ( znand 产品线)可能又用了别的 op
    redsonic
        26
    redsonic  
       2017-11-24 12:33:05 +08:00
    冗余空间全坏肯定 SSD 要归西,但反过来不成立。 很多 SSD 都是中了即死技挂掉的,比如主控算法 bug,映射表错误,缺乏掉电保护。SSD 就是 raid 控制器+存储片子,raid 挂了数据都在也读不出来。SSD 也不可能像传统 raid 那样支持 metadata 的备份。企业级的高端货不清楚,说错了请补充。
    twistedmeadows
        27
    twistedmeadows  
       2017-11-24 13:12:20 +08:00 via Android   ❤️ 1
    @honeycomb 诶,但是其实,NAND 厂商提供的闪存并不会专门对齐 64G、128G。
    所以用户端如果能用的容量有 128GB,那实际可用容量多半是大于 128G 的啦
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3765 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 34ms · UTC 00:50 · PVG 08:50 · LAX 17:50 · JFK 20:50
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.