Re: [RFT] major libata update

[Tejun Heo <htejun@gmail.com>]

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.

-- 
tejun