Linux下高效测试TF卡寿命：基于inode追踪的精准擦写方案

1. 为什么你需要一个更聪明的TF卡寿命测试方案？

在嵌入式开发或者树莓派这类单板计算机的项目里，TF卡（Micro SD卡）是我们的“系统盘”和“数据仓库”。但和电脑里的固态硬盘不同，TF卡，尤其是消费级的，其寿命（P/E Cycle，即擦写次数）往往是个黑盒。厂家可能只标注速度等级（Class 10, A1, A2），但对于最重要的“这块卡到底能反复写多少次”，常常语焉不详。

我遇到过不少糟心的情况：项目跑得好好的，突然系统变只读了，或者视频录像开始丢帧。一查，大概率是TF卡的某个或某些存储单元到达了擦写寿命。传统的测试方法是什么？很多人会想到用 dd 命令或者 fio 工具进行全盘顺序写入测试，写满、擦除、再写满，如此循环。这种方法固然有效，但效率实在太低了。一张32GB的卡，写满一遍就要不少时间，要测出寿命可能需要数天甚至数周。对于有明确工期（比如你提到的15天结项）的项目来说，这简直是噩梦。

更关键的是，这种“全盘雨淋”式的测试，真的能准确反映我们实际使用场景下的寿命吗？在我们的典型应用中，往往是几个关键文件（比如日志文件、数据库索引、视频索引块）在被高频度地反复擦写。我们需要的是一个“狙击枪”方案，能够精准地、持续地对一个或几个固定的物理存储位置进行压力测试，这样才能最快地模拟出真实损耗，验证TF卡是否达标。

所以，问题的核心就变成了：在Linux文件系统下，我们能否让一个文件始终“住”在TF卡的同一个物理位置，然后反复擦写它？ 答案是肯定的，而这把“狙击枪”的瞄准镜，就是文件的 inode（索引节点）。

2. 理解Linux文件系统的基石：inode与物理地址的映射

要玩转这个方案，我们得先搞明白Linux是怎么管理文件的。别担心，我们不钻牛角尖，只讲和测试相关的核心概念。

你可以把TF卡想象成一个巨大的、分成很多小格子（扇区，通常512字节）的仓库。文件系统（如ext4）就是这个仓库的管理员。管理员手里有一本超级详细的账本，这个账本里的一条核心记录就叫 inode。每个文件（或目录）都对应一个唯一的inode编号。

这个inode里记录了关于这个文件的所有元数据：文件大小、所有者、权限、时间戳，以及最关键的信息——这个文件的数据内容具体存放在仓库的哪些小格子里。这些“小格子地址”就是数据块的物理位置（更准确地说，是逻辑块地址，由闪存转换层FTL映射到物理块）。

当我们用 ls -i 命令时，看到的就是文件的inode编号：

ls -i my_test_file.bin

这个数字本身不代表地址，但它是一个稳定的“身份证号”。只要文件不被删除和重新创建，它的inode号在同一个文件系统内通常是保持不变的。

那么，inode号不变，是否意味着文件数据占用的物理存储位置也不变呢？ 这正是我们测试方案的理论基础。在大多数情况下，对于一个已存在的文件，进行覆盖写入（overwrite）或追加写入（append），文件系统会尽量复用之前分配给它的数据块。这就为我们定点擦写提供了可能。

3. 实战：设计基于inode追踪的定点擦写测试程序

理论说得差不多了，我们直接上手。我们的目标是：创建一个文件，然后以固定的频率（比如每秒一次）向其中写入数据并同步到磁盘，确保每次写入都作用于TF卡上相同的物理区域，直到该区域出现写入错误或达到预设的循环次数。

3.1 测试程序的核心逻辑与C语言实现

下面是一个用C语言编写的、简单直接的测试程序。它比脚本更底层，能更好地控制写入和同步操作。

#include <stdio.h>
#include <stdlib.