4 ms·
This is data loss. A few object files in the Git directory are truncated. Which results in a corrupted repository, from Git's point of view.
by ylyn 6y ago
This is data loss. A few object files in the Git directory are truncated.
Which results in a corrupted repository, from Git's point of view.
- TylerE 6y agoThat’s corruption. Data loss would indicate an entire fs transaction getting dropped entirely - but not breaking the principle of atomic ops. A write should either happen entirely or not at all.
- stretchcat 6y agoDoes git actually attempt to write all objects atomically?
- Someone 6y ago“A write should either happen entirely or not at all.” I think many modern file systems try really hard to make that true, but I don’t think you can count on it. “man write” (https://man7.org/linux/man-pages/man2/write.2.html https://man7.org/linux/man-pages/man2/write.2.html) still says: “Note that a successful write() may transfer fewer than count bytes” It also says “A successful return from write() does not make any guarantee that data has been committed to disk. On some filesystems, including NFS, it does not even guarantee that space has successfully been reserved for the data” That should be handled by calling fsync, but of course, if that fails, there’s not a lot you can do (even if you exactly know what happened) (https://research.cs.wisc.edu/adsl/Publications/atc20-cuttlefs.pdf https://research.cs.wisc.edu/adsl/Publications/atc20-cuttlef...) I also don’t think calling data loss due to writes that do not make it to disk “file system corruption” is correct. For file system corruption, the file system data structures have to be overwritten (e.g. the boot record or directory data structures)
- megous 6y agoCorruption is when you write data and you read back different data of the same size. Data loss is when you write data and you read back correct data of the smaller size or nothing. Not sure what you mean by entire fs transaction. But Linux doesn't have transactional fs interface, so open, write, close can be interrupted at any point with result of just having a new empty file after open, being one of the valid outcomes after crash.
- bonzini 6y agoFilesystems don't try to order writes to different files. So you get HEAD pointing to a truncated commit, or a commit pointing to a truncated blob. The same happens if you have a power loss or kernel crash on Linux (as a kernel developer, it happened to me several times when testing freshly-committed code).
- admax88q 6y agoGood to know, seems like a design flaw in git then, unless its using fsync correctly.