# 

云服务器一次异常重启之后，运维打开配置文件，看到的是三周前的旧版本。路径对、权限对、文件也在，就是内容退回去了。同一目录下另一份几乎同时写的文件，内容却是最新的那一版。

先怀疑回滚被误触发，翻了操作记录，没有；再怀疑云盘，查了监控和实例事件，也没有。原因藏在所有云上服务都在用的一套写法里：写临时文件、刷盘、改名替换。写法本身没错，漏掉的是对父目录的那一次刷盘。

## 文件还在，为什么内容读出来是空的？

常规实现是同目录建临时文件，写入新内容，关闭前刷一次盘，最后改名顶替正式文件。多数实现到这里就结束，因为单机上它几乎不出错。

崩在改名之前，重启后看到的是完整旧文件加一个残留临时文件，这种最无害。崩在改名之后、目录变更还没落盘，麻烦才来：内存里新名字已经指向新 inode，磁盘上的目录还是旧映射，重启后读回来仍指旧 inode，而它的数据块可能已被回收。

于是「文件还在」是因为目录项一直存在，「内容空」是因为那个目录项指向的不是你以为的东西。

## 手册里 fsync 到底承诺了什么？

答案比多数人以为的窄，手册写得很直接：

> fsync() transfers ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) so that all changed information can be retrieved even if the system crashes or is rebooted. This includes writing through or flushing a disk cache if present. The call blocks until the device reports that the transfer has completed.
> As well as flushing the file data, fsync() also flushes the metadata information associated with the file (see inode(7)).

两句话两个范围：先是描述符所指那个文件的 in-core 数据，再补上这个文件自己的 inode 元数据。主语始终锁在 the file referred to by the file descriptor 上，没有一个字提到目录。

所以只刷文件不刷目录的实现，能在测试环境跑一年不出事，遇到一次强制重启就翻车。它靠的不是接口保证，是运气。

## 内容刷下去了，文件名为什么没刷下去？

因为目录也是一个文件。它有 inode、有数据块，块里存的是名字到 inode 编号的映射。创建、改名、删除，动的都是这张表。

> Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.

explicit 是重点：必须显式地对目录的文件描述符再刷一次。目录不在这次调用的覆盖范围里，只能等内核按自己的节奏回写，而那个节奏在掉电时不可控。

| 步骤 | 落盘了什么 | 漏掉会怎样 |
| --- | --- | --- |
| 写临时文件内容 | 数据块 | 新文件读出来是空的 |
| 刷临时文件描述符 | 该文件 inode 与数据 | 文件存在但长度为零 |
| 改名到正式路径 | 内存里的目录映射 | 重启后名字指回旧 inode |
| 刷父目录描述符 | 目录项本身 | 前三步全部作废 |

只刷直接父目录对多数场景够用；但改名若跨越两级目录，两层都要刷，否则上层路径可能整体不见。

## 原子替换为什么还是回退了？

原子和持久是两个维度。rename 保证观察者此刻看到的要么是旧文件要么是新文件，看不到中间态；并不保证新状态在掉电后还在。

正确顺序可以收敛成一个函数，四步写死：

```c
int replace_file(const char *dir, const char *name, const void *buf, size_t len)
{
    char tmp[PATH_MAX];
    snprintf(tmp, sizeof(tmp), "%s/.%s.tmp", dir, name);

    int fd = open(tmp, O_WRONLY | O_CREAT | O_TRUNC, 0644);
    if (fd < 0) return -1;

    if (write_all(fd, buf, len) != (ssize_t)len) { close(fd); return -1; }
    if (fsync(fd) != 0)  { close(fd); return -1; }   /* 新文件的数据与 inode */
    close(fd);

    if (rename(tmp, name) != 0) return -1;           /* 只改了内存里的目录项 */

    int dfd = open(dir, O_RDONLY | O_DIRECTORY);
    if (dfd < 0) return -1;
    if (fsync(dfd) != 0) { close(dfd); return -1; }  /* 目录项真正落盘 */
    close(dfd);
    return 0;
}
```

每一步的返回值都检查，因为同步失败不会自己喊出来。

## fdatasync 能省掉哪一次刷盘？

省掉的是「不影响后续读取的元数据」。手册在同一节末尾还补了几段，正好覆盖常被问到的三件事：

> fdatasync() is similar to fsync(), but does not flush modified metadata unless that metadata is needed in order to allow a subsequent data retrieval to be correctly handled. ... On the other hand, a change to the file size (st_size, as made by say ftruncate(2)), would require a metadata flush.
> In Linux 2.2 and earlier, fdatasync() is equivalent to fsync(), and so has no performance advantage.
> An error occurred during synchronization. This error may relate to data written to some other file descriptor on the same file. Since Linux 4.13, errors from write-back will be reported to all file descriptors that might have written the data which triggered the error.

第一段的意思是：元数据只要不影响后续把数据读出来就可以不刷，但文件大小变了必须刷，它决定读到哪儿算结尾。第三段讲错误归属：别的描述符写坏的数据，也可能在你这次同步时把错误报给你。

| 接口 | 刷数据 | 刷元数据 | 常见用途 |
| --- | --- | --- | --- |
| fsync | 是 | 是 | 改名替换、配置文件 |
| fdatasync | 是 | 仅必要时 | 追加写的大文件 |
| O_SYNC 写 | 每次写都刷 | 视情况 | 低吞吐审计流水 |

表里第二行省下的开销在追加写场景很可观；但改名替换依赖 inode 与目录，省它就是埋雷。

## 云盘快照能不能当成保险？

不能当成同一层保险。快照是块设备级的，回滚会把当时的中间状态一起还原，包括那次没做完的改名。写入本来就缺目录刷盘的话，快照只是把这份不确定复制了一份。

| 手段 | 能保住什么 | 挡不住什么 |
| --- | --- | --- |
| 云盘快照 | 某时刻的块设备状态 | 回滚到改名没落盘的中间态 |
| 实例停机迁移 | 进程不再写入 | 停机前的未落盘变更 |
| 只做文件刷盘 | 文件内容完整 | 目录映射丢失 |

前三行都只是降低概率，只有文件加目录都刷才消除语义缺口。

## 现场怎么确认目录项有没有落盘？

最省事的办法是跟踪系统调用，看改名之后有没有对目录描述符的同步：

```bash
# 只看与落盘相关的调用，-f 跟进子进程，-s 放大显示长度
strace -f -e trace=openat,write,fsync,fdatasync,rename,renameat2 -s 128 -p <pid>
# 重点看两处：rename 之前有没有 fsync 文件，rename 之后有没有 fsync 目录
```

也可以从时间线上判断，一次典型事故的调用序列大致是这样：

```text
T0  openat(dir/.cfg.tmp, O_CREAT|O_WRONLY)  -> fd=7
T1  write(7, buf, 4096)                     -> 4096
T2  fsync(7)                                -> 0     数据和 inode 已落盘
T3  close(7)
T4  rename(dir/.cfg.tmp, dir/app.conf)      -> 0     仅内存里的目录项变更
T5  <掉电>                                  -> 目录项未刷，重启后仍是旧映射
```

T5 落在改名与目录刷盘之间，是这类事故最典型的窗口。窗口宽度取决于内核回写节奏，可能几毫秒，也可能几十秒，所以复现时好时坏。

## 这套写法后来怎么固定的？

三件事：把替换收敛成一个函数，四步顺序写死；评审清单加一条，凡是改名替换必须能看到目录刷盘；启动自检比对实际加载的配置版本号与预期版本号。

这套排查一开始散在几次复盘里，后来用 AI墨衍 整理成按现象、验证命令、结论三列排的对照表，值班的人照着走一遍就能定位缺了哪一步。

## 常见问题

**问：只刷目录不刷文件行不行？**

答：不行。目录项指向的 inode 还是空的，名字落盘了也一样读到空内容。

**问：用 O_SYNC 打开文件，还需要目录刷盘吗？**

答：需要。O_SYNC 影响的是该描述符上的写操作，目录项变更不在覆盖范围内。

## 小结

三句话：fsync 只保证描述符所指文件的内容与自身元数据，不保证目录项；改名替换要四步走全，漏掉目录刷盘等于把正确性交给运气；同步的返回值必须逐个检查。


云服务器一次异常重启之后，运维打开配置文件，看到的是三周前的旧版本。路径对、权限对、文件也在，就是内容退回去了。同一目录下另一份几乎同时写的文件，内容却是最新的那一版。

断电重启后文件还在，内容却是空的：fsync 落盘不等于落在目录

人工智能

云服务器重启后配置文件回退到旧版，根因是文件替换时漏掉对父目录的fsync刷盘。仅刷文件不刷目录，导致目录项未持久化，重启后指向旧inode。修复需按四步顺序：写临时文件、刷文件、改名、刷父目录，确保原子替换与持久性同步完成。

云服务器

代码解释

服务器

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

断电重启后文件还在，内容却是空的：fsync 落盘不等于落在目录-腾讯云开发者社区-腾讯云

断电重启后文件还在，内容却是空的：fsync 落盘不等于落在目录

断电重启后文件还在，内容却是空的：fsync 落盘不等于落在目录

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐