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

[Eric Sandeen]

On 4/14/11 4:27 AM, Michał Piotrowski wrote:
> W dniu 14 kwietnia 2011 11:19 użytkownik Andreas Schwab
> <schwab at redhat.com> napisał:
>> 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.
> 
> Do you see something unusual here?
> 
> [    3.926076] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
> [    3.926084] EXT4-fs (sda1): write access will be enabled during recovery
> [    4.655780] EXT4-fs (sda1): orphan cleanup on readonly fs
> [    4.655813] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
> unreferenced inode 269578
> [    4.656046] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
> unreferenced inode 131130
> [    4.656179] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
> unreferenced inode 131111
> [    4.656250] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
> unreferenced inode 271833
> [    4.656380] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
> unreferenced inode 271832
> [    4.656455] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
> unreferenced inode 269763
> [    4.656633] EXT4-fs (sda1): ext4_orphan_cleanup: deleting
> unreferenced inode 131082
> [    4.656696] EXT4-fs (sda1): 7 orphan inodes deleted
> [    4.656701] EXT4-fs (sda1): recovery complete
> [    4.667494] EXT4-fs (sda1): mounted filesystem with ordered data
> mode. Opts: (null)
> 

No, that's all normal recovery.

What kind of SSD is it?  SSDs being rather new beasts, with various different firmware implementations.... it's also possible that a barrier was ignored, etc... but hard to say.
 
-Eric

> 
>>
>>> It seems to me that the repairing git repo without a deep knowledge of
>>> it can be rather difficult.
>>
>> gitrepository-layout(5)
> 
> Thanks for the pointer
> 
>>
>> Andreas.
>>
>> --
>> Andreas Schwab, schwab at redhat.com
>> GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
>> "And now for something completely different."
>>
> 
> 
>