Tejun Heo wrote:

> 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.  :-(
>
Attached is the boot.msg file - one important note is that we (EMC) have 
the unusual habit of using drives with write cache off & turning them on 
during boot up.  Could be that the answer is a simple enabling write 
cache does not properly toggle the barrier support (although I thought 
that we had patches from Jens ? that fixed this).

ric