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

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

phillips@bonn-fries.net said:
> How can a drive can accept a command while it is disconnected from the
> bus. Did you mean that after it reconnects it might refuse the ordered
> tag and accept another?  That would be a bug, I'd think. 

Disconnect is SCSI slang for releasing the bus to other uses, it doesn't imply 
electrical disconnection from it.  The architecture of SCSI is like this, the 
usual (and simplified) operation of a single command is:

- Initiator selects device and sends command and tag information.
- device disconnects
....
- device reselects initiator, presents tag and demands to transfer data (in 
the direction dictated by the command).
- device may disconnect and reselect as many times as it wishes during data 
transfer as dictated by its flow control (at least one block of data must 
transfer for each reselection)
- device disconnects to complete operation
...
- device reselects and presents tag and status (command is now complete)

A tag is like a temporary ticket for identifying the command in progress.

During the (...) phases, the bus is free and the initiator is able to send 
down new commands with different tags.  If the device isn't going to be able 
to accept the command, it is allowed to skip the data transfer phase and go 
straight to status and present a QUEUE FULL status return.  However, there is 
still a disconnected period where the initiator doesn't know the command won't 
be accepted and may send down other tagged commands.

> It would mean we would have to wait for completion of the tagged
> command before submitting any more commands.  Not nice, but not
> horribly costly either. 

But if we must await completion of ordered tags just to close this hole, it 
makes the most sense to do it in the bio layer (or the journal layer, where 
the wait is currently being done anyway) since it is generic to every low 
level driver.

James