noisy reservation conflicts
While testing persistent reservations it is quite common to get a status of "reservation conflict". When using the SG_IO ioctl this status is returned via the sg_io_hdr::status field and is simple to process.
However this lk 2.6.7-rc3 code fragment in scsi_decide_disposition() [scsi_error.c] makes it very noisy (on the console and in the log):
case RESERVATION_CONFLICT:
printk("scsi%d (%d,%d,%d) : reservation conflict\n",
scmd->device->host->host_no,
scmd->device->channel,
scmd->device->id, scmd->device->lun);
return SUCCESS; /* causes immediate i/o error */The unadorned printk() looks like debugging code. Could this be softened, or removed in the case of a RQ_SPECIAL?
Doug Gilbert
Quoted 9 lines · Douglas Gilbert [[email protected]] wrote:
While testing persistent reservations it is quite common to get a status of "reservation conflict". When using the
SG_IOioctl this status is returned via thesg_io_hdr::statusfield and is simple to process.However this lk 2.6.7-rc3 code fragment in
scsi_decide_disposition()[scsi_error.c] makes it very noisy (on the console and in the log):
Quoted 7 lines
case RESERVATION_CONFLICT:
printk("scsi%d (%d,%d,%d) : reservation conflict\n",
scmd->device->host->host_no,
scmd->device->channel,
scmd->device->id, scmd->device->lun);
return SUCCESS; /* causes immediate i/o error */If we think it is important enough to leave we should wrap it with either a SCSI_LOG_MLCOMPLETE or SCSI_LOG_ERROR_RECOVERY to stay consistent with the scsi_decide_disposition function. Though I think the use of SCSI_LOG_ERROR_RECOVERY maybe should be replaced with SCSI_LOG_MLCOMPLETE in scsi_decide_disposition.
The upper level drivers could also report similar info if this was removed as sd has SCSI_LOG_HLCOMPLETE that should cover sg_io ios through sd and sg_cmd_done has SCSI_LOG_TIMEOUT (correct?).
-andmike
--
Michael Anderson
[email protected]
Quoted 24 lines · Mike Anderson
Quoted 9 lines · Douglas Gilbert [[email protected]] wrote:
While testing persistent reservations it is quite common to get a status of "reservation conflict". When using the
SG_IOioctl this status is returned via thesg_io_hdr::statusfield and is simple to process.However this lk 2.6.7-rc3 code fragment in
scsi_decide_disposition()[scsi_error.c] makes it very noisy (on the console and in the log):Quoted 7 lines
case RESERVATION_CONFLICT: printk("scsi%d (%d,%d,%d) : reservation conflict\n", scmd->device->host->host_no, scmd->device->channel, scmd->device->id, scmd->device->lun); return SUCCESS; /* causes immediate i/o error */If we think it is important enough to leave we should wrap it with either a
SCSI_LOG_MLCOMPLETEorSCSI_LOG_ERROR_RECOVERYto stay consistent with thescsi_decide_dispositionfunction. Though I think the use ofSCSI_LOG_ERROR_RECOVERYmaybe should be replaced withSCSI_LOG_MLCOMPLETEinscsi_decide_disposition.
Quoted 3 lines
The upper level drivers could also report similar info if this was removed as sd has
SCSI_LOG_HLCOMPLETEthat should coversg_ioios through sd andsg_cmd_donehasSCSI_LOG_TIMEOUT(correct?).
Sounds reasonable, but if you are going to be changing this anyway...you might as well put in the STONITH option. In order for scsi reservations to be a reliable method of host interaction control on a shared device, you need the ability for a reservation conflict to cause the machine that got the conflict to fall over dead (aka STONITH, Shoot The Other Node In The Head). If you don't have a remote controlled power switch, then you can implement this in the SCSI stack with a panic on reservation conflict. The basic scenario then is that in a multi-node failover cluster, the primary machine starts up and gets the reservation, then as long as it holds it everything is fine. If the primary machine fails its status check by the failover node, then the failover node can cause a bus reset, steal the reservation, and pick up where the main node left off (speaking specifically of SCSI-2 reservations here obviously). In that case, the next time the main node tries to access the device, it will get a reservation conflict and that is the main node's signal to panic/reboot and come back as the new failover node with the failover node now the primary node. Simple 4 line change required to make SCSI-2 reservations useful.
Signature · 4 lines
Doug Ledford <[email protected]> 919-754-3700 x44233 Red Hat, Inc. 1801 Varsity Dr. Raleigh, NC 27606
PATCH 1/1 lk 2.6.7-bk6 [Re: noisy reservation conflicts]
In reply to Mike AndersonQuoted 26 lines · Mike Anderson
Quoted 9 lines · Douglas Gilbert [[email protected]] wrote:
While testing persistent reservations it is quite common to get a status of "reservation conflict". When using the
SG_IOioctl this status is returned via thesg_io_hdr::statusfield and is simple to process.However this lk 2.6.7-rc3 code fragment in
scsi_decide_disposition()[scsi_error.c] makes it very noisy (on the console and in the log):Quoted 7 lines
case RESERVATION_CONFLICT: printk("scsi%d (%d,%d,%d) : reservation conflict\n", scmd->device->host->host_no, scmd->device->channel, scmd->device->id, scmd->device->lun); return SUCCESS; /* causes immediate i/o error */If we think it is important enough to leave we should wrap it with either a
SCSI_LOG_MLCOMPLETEorSCSI_LOG_ERROR_RECOVERYto stay consistent with thescsi_decide_dispositionfunction. Though I think the use ofSCSI_LOG_ERROR_RECOVERYmaybe should be replaced withSCSI_LOG_MLCOMPLETEinscsi_decide_disposition.
Quoted 3 lines
The upper level drivers could also report similar info if this was removed as sd has
SCSI_LOG_HLCOMPLETEthat should coversg_ioios through sd andsg_cmd_donehasSCSI_LOG_TIMEOUT(correct?).
Mike,
Yes the sg driver uses SCSI_LOG_TIMEOUT to avoid other usages and a logging loop.
Just so this thread isn't forgotten, attached is a patch to wrap the printk in question in a SCSI_LOG_ERROR_RECOVERY macro.
Doug Gilbert
drivers/scsi/scsi_error.c267bk6rc renamed from drivers/scsi/scsi_error.c +4 -3
@@ -1375,9 +1375,10 @@ return SUCCESS; case RESERVATION_CONFLICT: - printk("scsi%d (%d,%d,%d) : reservation conflict\n", - scmd->device->host->host_no, scmd->device->channel, - scmd->device->id, scmd->device->lun); + SCSI_LOG_ERROR_RECOVERY(5, printk("scsi%d (%d,%d,%d) : " + "reservation conflict\n", + scmd->device->host->host_no, scmd->device->channel, + scmd->device->id, scmd->device->lun)); return SUCCESS; /* causes immediate i/o error */ default: return FAILED;