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

James Bottomley
2002-03-04T14:58:20Z

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