Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
rwheeler at redhat.com
Thu Apr 14 12:11:11 UTC 2011
On 04/14/2011 05:19 AM, Andreas Schwab wrote:
> Michał Piotrowski<mkkp4x4 at gmail.com> writes:
>> W dniu 14 kwietnia 2011 11:04 użytkownik Andreas Schwab
>> <schwab at redhat.com> napisał:
>>> Michał Piotrowski<mkkp4x4 at gmail.com> writes:
>>>> But the question remains - should enabled barriers protect against
>>>> such data loss/breakage? Or I just had a big bad luck?
>>> It could also be a bug in git, perhaps it needs to take more care to
>>> create the ref file atomically.
>> Should I report it to upstream or in bugzilla.redhat.com?
> Looking closer it seems like git already does the right thing
> (open("master.lock"), write(sha1), rename("master.lock", "master")), so
> it appears to be a barriers issue.
If the files exist, but do not have newly written data, you will still need an
fsync() in there somewhere I think....
Barriers are responsible for meta-data, apps still need fsync() or fdatasync()
to commit the new user data.
>> It seems to me that the repairing git repo without a deep knowledge of
>> it can be rather difficult.
More information about the devel