Re: [PATCH] 2.4.x write barriers (updated for ext3)

[James Bottomley <James.Bottomley@SteelEye.com>]

mason@suse.com said:
> 1) The drivers would need to be changed to properly keep tag ordering
> in place on resets, and error conditions. 

And actually theres also a problem with  normal operations that disrupt flow 
control like QUEUE FULL returns and contingent allegiance conditions.

Basically, neither the SCSI mid-layer nor the low level drivers were designed 
to keep absolute command ordering.  They take the chaotic I/O approach:  you 
give me a bunch of commands and I tell you when they complete.

> 2) ordered tags force ordering of all writes the drive is processing.
> For some workloads, it will be forced to order stuff the journal code
> doesn't care about at all, perhaps leading to lower performance than
> the simple wait_on_buffer() we're using now.

> 2a) Are the filesystems asking for something impossible?  Can drives
> really write block N and N+1, making sure to commit N to media before
> N+1 (including an abort on N+1 if N fails), but still keeping up a
> nice seek free stream of writes? 

These are the "big" issues.  There's not much point doing all the work to 
implement ordered tags, if the end result is going to be no gain in 
performance.

> 4) If some scsi drives come with writeback on by default, do they also
> turn it on under high load like IDE drives do? 

Finally, an easy one...the answer's "no".  The cache control bits are the only 
way to alter caching behaviour (nothing stops a WCE=1 operating as write 
through if the drive wants to, but a WCE=0 cannot operate write back).

James