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

[Eric Sandeen]

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.  :)

-Eric
 
>>
>> -Eric