On 4/14/11 8:50 AM, Michał Piotrowski wrote: > W dniu 14 kwietnia 2011 15:42 użytkownik Eric Sandeen > <sandeen@xxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
