Doug, > except the I_T nexus on which the command causing the change was > received with the additional sense code set to CAPACITY DATA HAS > CHANGED." > > So seeing I'm using the I_T nexus that sent the FORMAT UNIT, then no > Unit Attention is expected, as per above. But that assumes that there is a single entity sending commands. Which is not the case here given that sg, unbeknownst to sd, is sending a FORMAT UNIT. We are not intercepting commands sent via sg to see if they may affect the ULDs. So we need some other way of finding out that the device has been reformatted behind our backs. > And surely the sd driver or mid-level should "smell a rat" after the > first: Unaligned partial completion error message. The disk was > unmounted so it should not be a big deal to run initialisation again > on it. While I agree that this particular error should be a red flag, we'll only see it if the new format deviates significantly from the old one. So smelling rats seems like papering over a limited subset of the possible issues resulting from a FORMAT UNIT. I wonder if it wouldn't be better to teach sg_format to revalidate a device once FORMAT UNIT completes? > If it was mounted then that would be an interesting situation, since > the user visible data (say just changed to 4096 byte LBs) would be the > concatenation of 8 of the previous 512 byte LBs. Maybe sg_format should check whether a block device is in use before it proceeds to send FORMAT UNIT? -- Martin K. Petersen Oracle Linux Engineering
