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.
See man 2 stat for 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.
来源：https://stackoverflow.com/questions/6478622/xfs-how-to-not-modify-mtime-when-writing-to-file