Re: [RFT] major libata update

[Ric Wheeler <ric@emc.com>]

Tejun Heo wrote:

> Ric Wheeler wrote:
>
>> May 17 03:30:54 centera kernel: [start_ordered           ]: BIO 
>> d08998c0 3357330 4096
>> May 17 03:30:54 centera kernel: [start_ordered           ]: ordered=1 
>> in_flight=0
>> May 17 03:30:54 centera kernel: [blk_do_ordered          ]: 
>> start_ordered ed3553c0->dfe2bd28
>> May 17 03:30:54 centera kernel: [elv_next_request        ]: dfe2bd28 
>> (bar)
>> May 17 03:30:54 centera kernel: [ordered_bio_endio       ]: 
>> q->orderr=0 error=0
>> May 17 03:30:54 centera kernel: [flush_dry_bio_endio     ]: BIO 
>> f18ffa00 3357330 4096
>> May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: ordseq=17 
>> seq=08 orderr=0 error=0
>> May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: sequence 
>> complete
>> May 17 03:30:54 centera kernel: [ordered_bio_endio       ]: 
>> q->orderr=0 error=0
>> May 17 03:30:54 centera kernel: [flush_dry_bio_endio     ]: BIO 
>> f18ff300 3357330 4096
>> May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: ordseq=17 
>> seq=08 orderr=0 error=0
>> May 17 03:30:54 centera kernel: [blk_ordered_complete_seq]: sequence 
>> complete
>
> [--snip--]
>
> Combined with your boot log, everything seems as expected.  Write 
> cache is disabled, so the chosen ordered mode is 0x1 - DRAIN only.  In 
> the log you've posted, there are no pending IOs on barrier issue, so 
> the barrier is executed directly and then the sequence is complete.  
> If there were other requests pending, all that happens would be 
> waiting for them to finish before issuing the barrier.
>
> If you turned on write cache after the machine booted, what method did 
> you use to turn on write cache?  If you issued the command directly 
> using sg to an active device (usage count >= 1), SCSI doesn't snoop 
> such commands and thus it won't adjust ordered mode automatically.  
> However, sd forces disk revalidation (and thus ordered 
> reconfiguration) if you change cache mode via 
> /sys/class/scsi_disk/X\:0\:0\:0/cache_type.
>
That is what I suspected...

The write cache gets set via hdparm (in the previous kernel we had just 
hacked the sd code to always assume write back/barriers until this /sys 
control came along ;-)).

What is the magic sequence to get the cache type to flip? My first tries 
to poke cache type leave it firmly in write through...

ric