2

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.

4

1 回答 1

3

参见man 2 statmtime 和 ctime 的语义。在实践中，mtime 和 ctime 将在 inode 的内存副本中更新，并异步刷新到磁盘。

如果没有主要的内核黑客，你不能跳过 inode 中的 mtime 更新，如果你真的认为从一个 32 位计数器复制到另一个内存位置会减慢你的速度，那么你错误地试图优化write(2).

想要提高 1GB 文件的文件写入性能？为块缓存添加更多内存以使用并忘记 mtime。

添加以回应评论

同步写入不会提供任何有意义的安全性，因为同步不会帮助在磁盘写入过程中拔掉电源线；这就是为什么使用像 xfs 和 ext3+ 这样的日志文件系统的原因。你所能期望的最好的就是面对失败时的一致性。

您似乎希望确定所记录的数据是一成不变的，即使您使用电池支持的 SRAM 写入缓冲区构建 RAID，这从根本上来说也是不可能的，因为在提交位之前总会发生故障。写入原始卷比日志文件系统提供的保护更少。

如果您在问题中阐明您的设计意图，则可能会有更好的答案。在直觉层面上，即使写入时间更长，对于一个 1GB 的小文件来说，闪存在我看来比旋转氧化物更不容易发生故障，但这不是一个正式的声明。

于 2011-06-25T15:23:13.137 回答