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

[Michał Piotrowski]

W dniu 14 kwietnia 2011 15:42 użytkownik Eric Sandeen
<sandeen at redhat.com> napisał:
> 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?

OCZ Vertex 2 with firmware 1.25 (this is not the latest version, but I
did not have too much courage to update it :))

[    1.548188] ata3.00: ATA-8: OCZ-VERTEX2, 1.25, max UDMA/133
[    1.548196] ata3.00: 97696368 sectors, multi 16: LBA48 NCQ (depth 0/32)
[    1.586184] ata3.00: configured for UDMA/133
[    1.586599] scsi 2:0:0:0: Direct-Access     ATA      OCZ-VERTEX2
  1.25 PQ: 0 ANSI: 5
[    1.587295] sd 2:0:0:0: Attached scsi generic sg0 type 0
[    1.587354] sd 2:0:0:0: [sda] 97696368 512-byte logical blocks:
(50.0 GB/46.5 GiB)
[    1.587835] sd 2:0:0:0: [sda] Write Protect is off
[    1.587844] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00

So far, I have not any problems with this drive (not counting not
working S.M.A.R.T. log).

>  SSDs being rather new beasts, with various different firmware implementations.... it's also possible that a barrier was ignored, etc... but hard to say.

Do the barriers are somehow dependent on the hardware? Maybe I need to
look in the SSD documentation to find out if proper commands are
supported?

>
> -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."
>>>
>>
>>
>>
>
>



-- 
Best regards,
Michal

http://eventhorizon.pl/