Hello all,
in open-iscsi, when network connectivity is lost, scsi commands that
were in-flight at the moment of disconnection are failed to the SCSI layer.
These get resubmitted up to 5 times by the SCSI layer (or so is written
in the open-iscsi docs) and after that they are held in the queue
(device "blocked") until the network connection is restored.
Now the question is: when SCSI resubmits commands to a device, I suppose
they go to the end of the queue for the device, and not at the head like
they were. Am I right?
How do filesystems, and in particular ext4, react to that?
I suppose the ordering goes awry, barriers cannot succeed in this way,
especially if they were submitted as real SCSI barriers (i.e. without
using flush + command + flush workaround)
Thank you
On 12/28/2010 04:41 AM, torn5 wrote:
> Hello all,
>
> in open-iscsi, when network connectivity is lost, scsi commands that
> were in-flight at the moment of disconnection are failed to the SCSI layer.
> These get resubmitted up to 5 times by the SCSI layer (or so is written
> in the open-iscsi docs) and after that they are held in the queue
> (device "blocked") until the network connection is restored.
>
> Now the question is: when SCSI resubmits commands to a device, I suppose
> they go to the end of the queue for the device, and not at the head like
> they were. Am I right?
The request goes to eh head. scsi layer calls
blk_requeue_request->elv_requeue_request->
elv_insert(ELEVATOR_INSERT_REQUEUE) and ELEVATOR_INSERT_REQUEUE's case
falls through to the ELEVATOR_INSERT_FRONT case.