磨损均衡算法介绍

磨损均衡算法介绍
🔥作者简介: 一个平凡而乐于分享的小比特,中南民族大学通信工程专业研究生,研究方向无线联邦学习
🎬擅长领域:驱动开发,嵌入式软件开发,BSP开发
❄️作者主页:一个平凡而乐于分享的小比特的个人主页
✨收录专栏:硬件知识,本专栏为记录项目中用到的知识点,以及一些硬件常识总结
欢迎大家点赞 👍 收藏 ⭐ 加关注哦!💖💖

磨损均衡算法介绍

有关磨损均衡技术的相关资料下载地址:磨损均衡技术相关论文

核心问题:为什么需要磨损均衡?

要理解磨损均衡,首先要明白Flash存储器(包括NAND Flash和NOR Flash)的物理限制:

  1. 有限的擦写次数: Flash存储单元在经历一定次数的擦除操作后,会因物理损耗而失效。这个次数就是耐久度
    • SLC NAND: ~10万次
    • MLC NAND: ~3千 - 1万次
    • TLC NAND: ~500 - 1.5千次
    • QLC NAND: ~100 - 500次
  2. 擦除操作的特殊性: Flash不能像RAM一样直接覆盖写入。它必须先进行擦除(通常按“块”进行,如128KB/256KB),将整个块变为“1”,然后才能进行编程(将需要的比特从“1”变为“0”)。

问题场景: 假设一个文件系统的元数据(如FAT表)固定存储在同一个Flash物理块上。每次文件更新,这个块都需要被擦写一次。即使这个块只能擦写1万次,在频繁写入的系统里,可能几周甚至几天就会用尽寿命,导致整个存储设备提前报废。而其他大部分块可能还“全新未使用”。

磨损均衡的目标就是:通过算法,让所有Flash物理块的擦写次数均匀分布,避免某些“热点”区块被过早写坏,从而将整个存储设备的总寿命延长至接近其理论最大值。


磨损均衡的实现层次与核心思想

磨损均衡算法主要在闪存转换层 中实现。FTL是介于文件系统(如FAT32, ext4)和物理Flash芯片之间的一个固件层,它负责地址转换、坏块管理、垃圾回收和磨损均衡

其核心思想是:将文件系统看到的“逻辑地址”与Flash存储器的“物理地址”分离开来,并动态地改变它们之间的映射关系。


主要磨损均衡算法分类

磨损均衡算法主要分为两大类:动态磨损均衡静态磨损均衡

1. 动态磨损均衡

这是最基本的形式。

  • 原理: 当需要写入新数据时,FTL总是从空闲块池中选择一个擦除计数最小的块(即“最年轻”的块)来使用。
  • 工作方式
    1. FTL维护一个所有空闲块的列表,并记录每个块的擦除次数。
    2. 当有写入请求时,算法从这个列表中找出擦除次数最少的块。
    3. 将数据写入该块,并更新逻辑到物理的地址映射表。
    4. 该块被移出空闲列表,其擦除计数增加。
  • 优点: 实现相对简单,能有效防止新写入的数据集中消耗少数几个块。
  • 缺点无法解决“冷数据”问题。如果一个数据写入后就不再修改(称为“冷数据”),那么它所占用的那个物理块就不会再被擦写,其磨损计数也就停滞了。而其他频繁变动的“热数据”区块则在持续磨损,导致块之间的磨损差异逐渐拉大。
2. 静态磨损均衡

这是更高级、更有效的方法,也是现代SSD和eMMC/UFS中的标准做法。

  • 原理: 不仅在选择空闲块时考虑磨损,还会主动地将“冷数据”从低磨损的块中搬移到高磨损的块中,从而让那些闲置的、低磨损的块也参与到磨损循环中来。
  • 工作方式
    1. 同样采用动态磨损均衡的策略来选择空闲块。
    2. 系统会周期性地或在特定条件下(如磨损差异超过某个阈值)启动数据迁移。
    3. FTL会寻找一个存放着“冷数据”的、磨损计数很低的物理块(Block A),以及一个磨损计数很高的空闲块(Block B)。
    4. 它将Block A中的有效数据复制到Block B中。
    5. 然后,更新地址映射表,指向新的Block B。
    6. 最后,将原来的Block A擦除,并放入空闲块池。这样,这个原本“闲置”的低磨损块就变成了可用块,准备接受新数据的写入。
  • 优点: 极大地改善了磨损的均匀性,使所有块的寿命得到最大程度的利用。
  • 缺点: 增加了写放大。因为复制冷数据本身会产生额外的写入操作,这些操作对用户来说是多余的,但为了均衡寿命又是必要的。

磨损均衡的关键技术与关联概念

磨损均衡不是孤立工作的,它与FTL的其他机制紧密耦合:

1. 垃圾回收
  • Flash中,当数据被更新时,旧数据所在的物理页会被标记为“无效”,新数据会写入新的空闲页。垃圾回收的任务就是回收这些包含无效数据的块。
  • 过程: GC会选择一个“脏块”(包含大量无效数据的块),将其中的“有效数据”复制到新的空闲块中,然后擦除整个“脏块”,使其变为可用的空闲块。
  • 与磨损均衡的关联在选择哪个块进行垃圾回收时,就会融入磨损均衡策略。GC算法不仅会看哪个块的无效页面最多,也会考虑哪个块的磨损计数较低,优先回收这些块,从而让它们进入空闲池,准备接受新的磨损。
2. 地址映射机制
  • FTL通过维护一个映射表,将逻辑地址映射到物理地址。当数据被更新时,FTL不是覆盖原物理地址,而是写入新的空闲地址,并更新映射表指向新位置。这称为异地更新
  • 这是实现磨损均衡的基础,因为正是这种“不覆盖”的特性,才使得FTL能够自由选择将数据写在哪个物理位置。
3. 写放大
  • 定义: 用户实际写入的数据量与实际写入Flash的物理数据量之间的比率。
  • 与磨损均衡的关系静态磨损均衡和垃圾回收都会显著增加写放大。因为它们在后台移动数据,产生了额外的写入操作。设计良好的算法需要在延长寿命(磨损均衡)降低写放大(提升性能和使用寿命) 之间取得平衡。

实际应用与例子

  • 固态硬盘: 所有SSD都内置了非常复杂的FTL固件,其中包含了成熟的动态和静态磨损均衡算法。这是SSD能够达到数年使用寿命的关键。
  • U盘和SD/TF卡: 中高端的存储卡也具备磨损均衡功能。但一些极其廉价的U盘可能没有或只有非常简单的算法,其寿命和稳定性也较差。
  • 嵌入式系统: 在基于SPI Flash的文件系统(如LittleFS, SPIFFS)中,也实现了轻量级的磨损均衡算法,以适应微控制器应用的需求。

总结

特性动态磨损均衡静态磨损均衡
核心思想将新数据写入最“年轻”的空闲块除了动态策略,还主动迁移“冷数据”
复杂度较低较高
效果较好极佳,能充分利用所有块
写放大较低较高(因数据迁移)
适用场景对寿命要求不极致的低成本设备所有高端、高可靠性存储设备(如SSD)

总而言之,磨损均衡是一种通过智能地管理数据物理存放位置,以确保Flash存储器每个物理区块的磨损程度尽可能均匀,从而最大化整个设备使用寿命的算法。它是现代大容量、高耐久度Flash存储设备不可或缺的“守护神”。

Read more

【VLA模型】架构全解+公式详解

【VLA模型】架构全解+公式详解

文章目录 * 目录 * 一、前置认知:VLA模型核心基础信息 * 1.1 VLA模型核心基础属性表 * 1.2 VLA模型发展历程关键节点表 * 二、VLA模型整体架构全解析 * 2.1 VLA模型整体架构核心对照表 * 2.2 VLA模型核心子架构详细拆解表 * 2.2.1 视觉编码器(特征提取核心) * 2.2.2 语言编码器(指令理解核心) * 2.2.3 动作编码器(历史信息捕捉核心) * 2.2.4 跨模态融合层(三模态关联核心) * 2.2.5 动作决策层(执行指令生成核心) * 三、VLA模型核心模块与关键公式详解 * 3.1 视觉特征编码(以ViT为例)

By Ne0inhk
企业级在线文档:ONLYOFFICE 核心优势深度解读与测评体验

企业级在线文档:ONLYOFFICE 核心优势深度解读与测评体验

在当今数字化转型的浪潮中,企业的办公模式正在经历从“单机作业”到“云端协同”的深刻变革。尤其是在混合办公、跨地域协作日益普遍的今天,寻找一款既能打破信息孤岛、提高团队协作效率,又能严格保障企业核心商业数据安全的文档处理引擎,成为了每一个 IT 架构师和企业决策者的核心诉求。 我们在评估过市面上众多协作工具后,最终将目光锁定在了 ONLYOFFICE 上。作为一款开源且功能强大的企业级在线文档套件,ONLYOFFICE 在实际业务场景中展现出了令人惊艳的稳定性和功能深度。今天,我就根据自己在企业内部署和试用 ONLYOFFICE 的第一手经验,从实时协作、数据安全、多设备支持等维度,深度解读它的核心优势,看看它是如何真正为企业降本增效的。 🚀 协同即生产力:极简且强大的实时协作体验 在企业日常运营中,最耗费精力的事情莫过于多部门共同编写同一份项目企划书或合并多张财务报表。传统模式下,文件需要在微信、邮件里丢来丢去,不仅版本极其容易混乱,沟通成本也高得惊人。而 ONLYOFFICE 作为一款企业级在线文档工具,完美地解决了这个痛点。 ONLYOFFICE 提供了两种非常贴合企业

By Ne0inhk
Spring Boot 后端分层开发实战:从 MVC 到三层架构详解

Spring Boot 后端分层开发实战:从 MVC 到三层架构详解

应用分层 通过上面的练习,我们学习了 Spring MVC 简单功能的开发,但是我们也发现了一些问题。目前我们程序的代码有点 “杂乱”,然而当前只是 “一点点功能” 的开发。如果我们把整个项目功能完成呢?代码会更加的 “杂乱无章”(文件乱,代码内容乱)。 也基于此,咱们接下来学习应用分层。类似公司的组织架构:公司初创阶段,一个人身兼数职,既做财务,又做人事,还有行政。随着公司的逐渐壮大,会把岗位进行细分,划分为财务部门,人事部门,行政部门等。各个部门内部还会再进行细分。 项目开发也是类似,最开始功能简单时,我们前后端放在一起开发,随着项目功能的复杂,我们分为前端和后端不同的团队,甚至更细粒度的团队。后端开发也会根据功能再进行细分。MVC 就是其中的一种拆分方式。但是随着后端人员不再涉及前端,后端开发又有了新的分层方式。 4.1 介绍 阿里开发手册中,关于工程结构部分,定义了常见工程的应用分层结构: 那么什么是应用分层呢?应用分层是一种软件开发设计思想,

By Ne0inhk
Flutter 组件 dart_dev 适配鸿蒙 HarmonyOS 实战:效能基座方案,构建全生命周期自动化开发流水线与研发套件治理架构

Flutter 组件 dart_dev 适配鸿蒙 HarmonyOS 实战:效能基座方案,构建全生命周期自动化开发流水线与研发套件治理架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 dart_dev 适配鸿蒙 HarmonyOS 实战:效能基座方案,构建全生命周期自动化开发流水线与研发套件治理架构 前言 在鸿蒙(OpenHarmony)生态迈向大规模工业化协同、涉及海量跨端功能并发验证及严苛代码交付质量标准的背景下,如何实现研发流程的“机器化”约束,已成为决定团队产出稳定性与效能上限的关键。在鸿蒙设备这类强调 AOT 极致性能与多包(HAP/HSP)协同部署的环境下,如果研发环节依然依赖分散的散装脚本或非标的 Git 工作流,由于由于环境配置的微差异,极易由于由于“本地通过,远端爆炸”导致集成交付效率的高频损耗。 我们需要一种能够统一任务调度(Task Runner)、支持全量规范校验且具备“一站式”研发脚本治理能力的基座方案。 dart_dev 为 Flutter 开发者引入了“研发即代码(Dev-as-Code)

By Ne0inhk