That massive filesystem thread

Posted Apr 2, 2009 20:23 UTC (Thu) by iabervon (subscriber, #722)
In reply to: That massive filesystem thread by bojan
Parent article: That massive filesystem thread

Linus actually overstated git's use of fsync(). There are three relevant cases:

git writes to a brand new filename, and then updates an existing file to contain the new filename instead of an old filename. It will optionally do a fsync() between these two operations.
git writes all of the data from several existing files to a single new file, and then removes the existing files. It will always do a fsync() between these two operations.
git updates an existing file by writing to a temporary file and renaming over the existing file. It will never do a fsync() between these two operations.

That is, git relies on the assumption that a rename() is atomic with respect to the disk and dependent on all operations previously issued on the inode that is being renamed. It uses fsync() only to make sure that operations to different files happen in the order that it wants.

Now, obviously, if you want to be really sure to keep some data, write it once and never replace it at all. That'll do a good job of protecting against everything, including bugs where you do something like "open(), fsync(), close(), rename()" but forget or mess up the "write()". Obviously, this isn't an option for a lot of situations, however, but it's what git does for the most important data.