xfs - 写入文件时如何不修改 mtime？
我有一个文件 a.dat，大小为 1GB，驻留在磁盘上。出于性能原因，我重用此文件并根据需要简单地覆盖其内容，而不是创建新文件并让它增长（每个增长操作都必须更新其 inode 中的大小）。
我试图挤出更多的性能，并在手册页中搜索了 open 和mount 尝试找出文件的 mtime 和 ctime 何时更新。根据我的理解，每次更改文件内容时，mtime 和/或 ctime 都会更新。这就是 xfs 的工作原理吗？
如果是这样，有没有办法在Linux上禁用它？我不关心 mtime 和 ctime，并且不想承担每次写入操作更新它们的成本。
最终，我将完全摆脱文件系统并直接写入设备，但与此同时，我希望有一种方法可以使用文件系统来做到这一点。
编辑答案
为了澄清起见，我正在写入 SSD，并且从 SSD 中挤出所有可以执行的操作非常重要。 SSD 理论上每秒可以处理 25K 次操作，每一个操作对我来说都很重要。我不希望它们中的任何一个被浪费在除了写入我的文件之外的任何事情上。就这一点而言，实际上我的磁盘上有 200 个 1GB 文件可供写入。我试图通过上面的问题来简化问题。
此外，每次写入都必须是同步的，并且在我确定这些位位于磁盘上（这是可能的）之前，我的程序不会继续。但我认为这个注释与问题无关。
I have a file, a.dat that is 1GB and resides on disk. For performance reasons, I reuse this file and simply overwrite its contents as needed, rather than creating a new file and letting it grow (each grow operation has to update its size in the inodes).
I am trying to squeeze even more performance out, and have searched the man pages for open and mount to try to figure out when the mtime and ctime for a file are updated. From my understanding, each time you change a file's contents, the mtime and/or ctime are updated. Is this how xfs works?
If so, is there a way to disable this on linux? I don't care about the mtime and ctime and would rather not incur the cost of updating them with each write operation.
Eventually, I will get rid of the filesystem completely and write directly to the device, but for the meantime I am hoping there is a way to do this with the filesystem.
EDIT IN RESPONSE TO ANSWER
For clarification, I am writing to an SSD and squeezing every operation I can out of the SSD is extremely important. The SSD can theoretically handle on the order of 25K operations per second, and each of these is important to me. I don't want any of them to be wasted on anything other than writing to my files. On that note, in reality I have 200 1GB files on my disk that I'm writing to. I was trying to simplify the problem with my question above.
Additionally, each write must be synchronous and my program will not continue until I am sure that the bits are on disk (which is possible). But I think this note is tangential to the question.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
有关 mtime 和 ctime 的语义，请参阅
man 2 stat。实际上，mtime 和 ctime 将在 inode 的内存副本中更新并异步刷新到磁盘。如果没有重大内核黑客行为，您就无法跳过 inode 中的 mtime 更新，并且如果您确实认为从一个 32 位计数器到另一个内存位置的复制会减慢您的速度，那么您错误地尝试优化
write 的快速部分(2)。想要提高 1GB 文件的写入性能吗？添加更多内存供块缓存使用，并忘记 mtime。
根据评论添加
同步写入不会提供任何有意义的安全性，因为同步不会帮助磁盘写入过程中拉动电源线；这就是使用 xfs 和 ext3+ 等日志文件系统的原因。你所能期望的最好的结果就是面对失败时保持一致。
您似乎希望确定所记录的数据是一成不变的，即使您使用电池支持的 SRAM 写入缓冲区构建 RAID，这从根本上来说也是不可能的，因为在提交比特之前，某些东西总是可能会失败。写入原始卷所提供的保护甚至比日志文件系统还要少。
如果您在问题中阐明您的设计意图，可能会得到更好的答案。从直觉上看，尽管写入时间更长，但对于一个微不足道的 1GB 文件来说，闪存让我觉得比旋转氧化物更不容易出现故障，但这并不是一个正式的声明。
See
man 2 statfor the semantics of mtime and ctime. In practice, the mtime and ctime will be updated in the in-memory copy of the inode and flushed out to disk asynchronously.You can't skip the mtime update in the inode without major kernel hackery and if you really think that a copy from one 32bit counter to another memory location is slowing you down, you are mistakenly trying to optimize the fast part of
write(2).Want to increase file write performance on a 1GB file? Add more memory for the block cache to use and forget about the mtime.
added in response to comment
Synchronous writes will not provide safety in any meaningful sense as a pulled power cord in the middle of a disk write is not helped by sync; this is why journaled filesystems like xfs and ext3+ are used. The best you can hope for is consistency in the face of failure.
You appear to desire certainty that the data recorded are cast in stone which is fundamentally impossible even if you build a RAID with battery backed SRAM write buffers as something can always fail before the bits are committed. Writing the raw volume gives you even less protection than a journaled filesystem.
If you clarify your design intention in your question, a better answer might be possible. On a gut level, even though the write times are longer, for a piddling little 1GB file, flash memory strikes me as less failure prone than spinning oxides, but this is not a formal declaration.