On Mon, 2016-09-12 at 10:20 +0200, Hannes Reinecke wrote: > SPC-2 and SPC-3 (or later) differ in the handling of reservation > conflict for TEST UNIT READY. SPC-2 will return 'reservation > conflict', whereas SPC-3 will return GOOD status. > On a mixed system with both SPC-2 and SPC-3 targets one will > see lots of 'reservation conflict' messages from the SPC-2 system but > no messages from the SPC-3 system when eg multipath path checkers. > These messages might confuse the unsuspecting user although in fact > they just signal normal operation. I don't agree with this: a SCSI-2 device will not get properly configured if it's reserved by something else, so you get other strange artifacts of this condition. > So we should not be printing out 'reservation conflict' for > TEST UNIT READY responses. This doesn't sound like a good rationale to me. The way I see it, if this message is actually useful, people would like to see it when they get a reservation conflict. That does mean even when SCSI-2 reservations give one where SCSI-3 would not. The other reason is that it tells you why your device didn't get configured properly: both Test Unit Ready and Read Capacity get conflicts with SCSI-2, whereas they do with SPC-3+ devices (trying to forget SPC-2). You could argue that the entire message needs removing, since it's reporting stuff that mostly only shows when systems using reservations correctly are in operation. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
