Jeff King <peff@xxxxxxxx> writes: > I had always assumed this was fine on ext4 with data=ordered (i.e., > either the rename and its pointed-to content will go through, or not; so > you either get your update or the old state, but not a garbage or empty > file). But it sounds from what Ted wrote in: > > http://article.gmane.org/gmane.linux.file-systems/97255 > > that this may not be the case. If it's not, I think we should consider > fsyncing ref writes. That matches my understanding. IIRC, we do fsync (without a knob to turn it off) packs, we do not fsync refs (as you described above), the index, or working tree files (via write_entry()). Among these: * If we are so paranoid that loss of new loose objects matter (as opposed to "Heh, it is just the matter of 'git add' again") to cause us to set core.fsyncObjectFiles, we should definitely fsync ref writes. They are even more precious. * The index is much less precious. In the worst case, you can 'git reset' (no flags) and re-add from the working tree and nothing unrecoverable is lost. I do not mind a knob to force us fsync, but we may want it to be separate from core.fsyncObjectFiles. * The working tree files? I am not sure. Again, recovery is just to run "git diff" to notice what was eaten by the power failure and then "git checkout $path" to restore from a known state, so... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
