设备开关机测试中JSON文件数据丢失问题咨询

会出现这种情况，核心原因和文件系统的写机制、NAND Flash特性以及当前代码的局限性直接相关：

1. fopen("w+")的截断行为优先触发 #

当用"w+"模式打开文件时，文件系统会立即执行文件截断操作——如果文件已存在就把它截为0长度，不存在则创建空文件。这个操作的元数据（比如文件大小的初始更新）通常会被文件系统优先处理，甚至可能在你调用fwrite之前就已经持久化到NAND Flash上。如果此时断电，后续的写入和fflush还未完成，文件系统恢复时会根据已持久化的元数据，把文件大小保留为后续写入的目标长度，但实际数据区域没有内容，只能填充为0。

2. fflush不保证数据落地到物理存储 #

fflush(pf)仅仅是把C标准库层面的用户态缓冲区数据刷到操作系统内核的页缓存里，完全不负责把内核页缓存的数据写入到NAND Flash这类物理存储。内核本身有延迟写策略，会攒够一定量的数据再批量写入，以此提升IO性能。所以即使fflush执行成功，数据依然可能停留在内存中，断电后直接丢失。

3. NAND Flash文件系统的元数据处理特性 #

针对NAND Flash设计的文件系统（比如UBIFS、YAFFS2），会通过日志、磨损均衡等机制管理数据和元数据。更新文件大小这类元数据时，文件系统通常会先把元数据写入日志区并持久化，而实际数据则暂存在页缓存中等待批量写入。断电后恢复时，文件系统会依据日志里的元信息恢复文件的大小属性，但未写入的数据区域只能用0填充，最终就出现了“大小正常但内容全0”的情况。

后续优化建议 #

• 调用fsync()：通过fileno(pf)从FILE*获取文件描述符后，调用fsync(fd)，它会强制把文件的内容和元数据都从内核页缓存刷到物理存储，是保证数据持久化的关键操作。
• 原子写入+备份：先写临时文件，完成写入并fsync后，再原子替换原文件；同时保留备份文件，避免单次写入失败导致的文件损坏。

内容的提问来源于stack exchange，提问作者work aaron