我们正在将我们的应用程序从 RHEL6.5 ext4 升级到 RHEL7.3 XFS。我们观察到，使用 XFS 文件系统进行冷重启（从系统控制台 - iLO）会将我们的一些文件（每隔几秒写入磁盘）截断为零字节。不仅是我们的应用程序，而且假设我们使用“>”将输出从一个命令重定向到一个文件，这些文件在冷重启后消失。我们知道关于明确执行 fysnc 的建议。但是我们的 Java 代码是什么？我们的 python 脚本中的案例呢？
现在我们处于两难的境地，是坚持使用 ext4 还是 XFS。XFS 有优势，将是我们的首选。我们不能相信世界其他地方没有意识到这一点。这是 RHEL 特有的问题（我们在 RHLE6.5 https://bugzilla.redhat.com/show_bug.cgi?id=845233中看到了一个类似的问题），或者这是现代文件系统的预期行为？
Java 和 Python 都在其 I/O 库中提供了对fsync操作的访问，所以这并不是一个真正的借口，但我理解你的意思。
但是，这方面的关键 ext4/XFS 差异通常是其他方面的。一个直
echo contents > file
即使使用 ext4，有时也会留下零长度文件，特别是如果写入的内容不仅仅是几个字节。保证在 ext4（使用默认配置）上工作的是：
echo contents > file.new
mv file.new file
使用 ext4-with-defaults，这将永远不会留下部分写入file（file.new可能是不完整的）。XFS在这方面不同，重命名前需要fsync编辑内容。
2014 年，Eric Sandeen 提出了一个补丁来将 XFS 行为与 ext4 的行为保持一致，但当时并没有得到很好的接受，也没有被合并。也许从那时起潮流已经转变，今天重新提出的补丁是可以接受的。（我没有在当前代码中看到刷新，但我不是 XFS 开发人员。）
如果这会阻止您迁移到 XFS，那么您绝对应该提交支持票。即使为此偏离上游内核确实不是一种选择，但这样的客户需求始终是重要的反馈。