update max sdev block limit

Updated patch to address comments from Andreas Herrman, who noted that the initialization, with the HZ, was inconsistent with its use in the FC transport.
--
This patch ups the maximum limit for how long an sdev is allowed to be blocked. Originally, the value was 60 seconds. However, we are aware of array failover and switch reboot times that can be as high as 90 seconds. We're proposing to change the max to 120 seconds.

-- james s

Signed-off-by James Smart <[email protected]>

diff -upNr a/drivers/scsi/scsi_priv.h b/drivers/scsi/scsi_priv.h

drivers/scsi/scsi_priv.h +1 -2

@@ -127,7 +127,7 @@ extern struct bus_type scsi_bus_type;
  * classes.
  */
 
-#define SCSI_DEVICE_BLOCK_MAX_TIMEOUT	(HZ*60)
+#define SCSI_DEVICE_BLOCK_MAX_TIMEOUT	120	/* units in seconds */
 extern int scsi_internal_device_block(struct scsi_device *sdev);
 extern int scsi_internal_device_unblock(struct scsi_device *sdev);
 
 
 
-

To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

I disagree with this patch.

My personal opinion is that the previous value of 6000 (assume HZ==100), or around 1 hour 40 minutes, was probably too long. But, 120 seconds is too short. I would suggest a MAX value of maybe 10 minutes, or 600 seconds. It appears that introducing an upper bound which is now more than an order of magnitude smaller than the previous value could have some impact at customer sites.

There are raid devices which require around 200+ seconds to crash, dump, reboot, and return on line. (Yes, I've timed it!)

Mike

Quoted 34 lines · James Smart

Updated patch to address comments from Andreas Herrman, who noted that the initialization, with the HZ, was inconsistent with its use in the FC transport.
--
This patch ups the maximum limit for how long an sdev is allowed to be blocked. Originally, the value was 60 seconds. However, we are aware of array failover and switch reboot times that can be as high as 90 seconds. We're proposing to change the max to 120 seconds.

-- james s

Signed-off-by James Smart <[email protected]>

diff -upNr a/drivers/scsi/scsi_priv.h b/drivers/scsi/scsi_priv.h

drivers/scsi/scsi_priv.h +1 -2

@@ -127,7 +127,7 @@ extern struct bus_type scsi_bus_type;
  * classes.
  */
 
-#define SCSI_DEVICE_BLOCK_MAX_TIMEOUT	(HZ*60)
+#define SCSI_DEVICE_BLOCK_MAX_TIMEOUT	120	/* units in seconds */
 extern int scsi_internal_device_block(struct scsi_device *sdev);
 extern int scsi_internal_device_unblock(struct scsi_device *sdev);
 
 
 
-

To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

I don't mind making it bigger, especially as this is just a max, not the default value. I tried to keep it low, as I believe even 2 mins is a long time from the system's perspective. 10 minutes is forever (and remember the scan deadlock that we just worked through).

Quoted 4 lines · James Smart

I don't mind making it bigger, especially as this is just a max, not the default value. I tried to keep it low, as I believe even 2 mins is a long time from the system's perspective. 10 minutes is forever (and remember the scan deadlock that we just worked through).

Yes, so add default and max settings instead of using the max as the default.

And I still don't see how the scsi timeout can (reliably) make it through these block/unblocks. EH_RESET_TIMER doesn't freeze the scsi timeout like you really need, just restarts it.

For example, with default sd timeout of 30, you could be one second into a command, block for 28 seconds, unblock, and then still timeout.