Skip to contentSkip to conversation

Ext4 and scsi commands resubmission

DISCUSSION torn5 2 participants 2 messages Dec 28, 2010 – Dec 29, 2010 SCSI

lore
Share & tools
lore

torn5

author
#0 lore raw

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

#1 lore raw
Quoted 11 lines · 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.