René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Potential for data corruption as writes are not followed by fsync?","articleBody":"I am interested in the durability of `libgit2` and found the following note:\r\n\r\n    do_fsync whether to do an fsync() after writing (currently ignored)\r\n\r\nhttps://github.com/libgit2/libgit2/blob/89c332e41b12a72d89de40d63bc568c56a2c336a/include/git2/odb_backend.h#L42\r\n\r\n### Reproduction steps\r\n\r\nWrite an object to the odb, update a ref, and suffer a power failure.\r\n\r\n### Expected behavior\r\n\r\nThe ref should point to a valid set of objects.\r\n\r\n### Actual behavior\r\n\r\nThe ref points to missing or partially written objects.\r\n\r\n### Version of libgit2 (release number or SHA1)\r\n\r\nCurrent.\r\n\r\nIt seems like fsync should be the default for reliable and durable behaviour. But, perhaps I'm wrong.\r\n\r\nIt's not enough to call close, you should call fsync before calling close.\r\n\r\n\u003e A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes. It is not common for a file system to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use fsync(2).\r\n\r\nI may be wrong, but it would be good to understand whether the git repository could be in an inconsistent state after a power loss and if this is by design or not.","author":{"url":"https://github.com/ioquatix","@type":"Person","name":"ioquatix"},"datePublished":"2017-02-13T14:03:53.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":20},"url":"https://github.com/4123/libgit2/issues/4123"}