Jeff Garzik wrote:
> Ric Wheeler wrote:
>>
>> One other note, it seems like this patch set has broken the write 
>> barrier support - is that a side effect of enabling NCQ still?
>>
>> I see messages that claim flush barriers are enabled:
>>
>> [root@c001n01 root]# mount -o 
>> barrier=flush,rw,noatime,nodiratime,data=ordered,notail /dev/sda10 /mnt/1
>> May 16 22:21:56 centera kernel: ReiserFS: sda10: found reiserfs format 
>> "3.6" with standard journal
>> [root@c001n01 root]# May 16 22:21:58 centera kernel: ReiserFS: sda10: 
>> using ordered data mode
>> May 16 22:21:58 centera kernel: reiserfs: using flush barriers
>> May 16 22:21:58 centera kernel: ReiserFS: sda10: journal params: 
>> device sda10, size 8192, journal first block 18, max trans len 1024, 
>> max batch 900, max commit age 30, max trans age 30
>> May 16 22:21:58 centera kernel: ReiserFS: sda10: checking transaction 
>> log (sda10)
>> May 16 22:21:58 centera kernel: ReiserFS: sda10: Using r5 hash to sort 
>> names
>>
>> But when I test with my synchronous write load, I am going at 6 times 
>> the normal rate (i.e., the rate I see with barriers disabled) ;-)
> 
> Well, NCQ read/write commands have a 'FUA' bit...  though maybe the NCQ 
> code forgot to check the global libata_fua.
> 

Hmmm.. The only place FUA is checked is ata_dev_supports_fua() 
regardless of NCQ, but I've seen FUA enabled with NCQ in another bug 
report, so I might have screwed up.  Ric, can you post the boot dmesg 
such that we know whether FUA is enabled or not?

I'm attaching a patch to print the progress of ordered sequence.  I've 
just tested with a NCQ drive loaded with 20 IO requests and it works. 
All requests are drained, preflush, barrier, then postflush.  Running 
the same test with the attached patch will tell us how barrier is working.

@ I can't believe this.  Last night two disks failed - one testing, one 
production.  Man, my harddrives are falling like flies.  Four test 
drives and one production drive failed during last two months.  Maybe 
they are striking back at me.  :-(

-- 
tejun