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

[Michał Piotrowski]

W dniu 14 kwietnia 2011 15:59 użytkownik Eric Sandeen
<sandeen at redhat.com> napisał:
> On 4/14/11 8:50 AM, Michał Piotrowski wrote:
>> W dniu 14 kwietnia 2011 15:42 użytkownik Eric Sandeen
>> <sandeen at redhat.com> napisał:
>
>
> ...
>
>
>>> 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 :))
>
> Ok.  We (the ext4 list) had a report a year ago or so where someone had really debugged some odd behavior with one ssd and its firmware, but not this one :)
>
> So not the same thing exactly, at least.
>
>> [    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?
>
> I don't think you'll find that sort of thing; it's a question of implementing the spec properly, really.  All I meant is that it is -possible- for hardware to be broken or noncompliant, so it's -possible- that that's what you're seeing.  I'm NOT saying that the OCZ-VERTEX2 -is- broken, just musing that the hardware needs to exhibit proper behavior as much as the application needs to issue the right data integrity syscalls.  :)

I think I'll try to update firmware on this drive over the weekend.
When I read things like that in firmware release notes

"Fixed rare corner case that could cause the drive to reset and clear user data"
"Fixed a rare condition that could cause the drive to reset and clear the data"

I begin to wonder if it was the right decision to change main drive to SSD :)

Maybe it's time to start using data=journal

>
> -Eric
>
>>>
>>> -Eric
>



-- 
Best regards,
Michal

http://eventhorizon.pl/