Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?

[Ric Wheeler]

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.

Ric

>> It seems to me that the repairing git repo without a deep knowledge of
>> it can be rather difficult.
> gitrepository-layout(5)
>
> Andreas.
>