On 2019-01-16 8:57 p.m., Martin K. Petersen wrote:
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.
I was trying to explain why you shouldn't be expecting a Unit Attention (UA)
after a format that changes the logical block size. The mode page block
descriptors also change and there is a UA for that but with the same
exclusion: not to the I_T that caused the change.
And there is no meaningful VPD or standard INQUIRY response data that has
changed, so no UA from that either.
Best for me to check with T10 before suggesting to the firmware folks they
have made a mistake. Seems to me that got it right (although I will check
from another I_T nexus and expect to get a UA there).
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.
If you google on that message, you will see various reports of it
polluting machine logs with users curious about what it means and why
there are so many of them.
I wonder if it wouldn't be better to teach sg_format to revalidate a
device once FORMAT UNIT completes?
So punch a hole through a few abstraction layers that make sg_format
platform independent for something another Linux driver needs and the
corresponding FreeBSD driver (da) works out itself?
According to my notes, Eric Youngdale wanted this added to the sg
driver late in the last millennium:
if (scsi_normalize_sense(sbp, sense_len, &ssh)) {
if (!scsi_sense_is_deferred(&ssh)) {
if (ssh.sense_key == UNIT_ATTENTION) {
if (sdp->device->removable)
sdp->device->changed = 1;
}
}
}
Perhaps the sg v4 driver could have an extra command flag or stretch the
SG_EXTENDED ioctl a little more to set sdp->device->changed . Alternatively
a call to sdev_evt_send_simple() so it could simulate a
SDEV_EVT_CAPACITY_CHANGE_REPORTED event.
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?
"in use" might be hard to define. sg_format has a 15 second "are you sure"
countdown before it starts its work. hdparm has "--you-do-know-what-you-are-
doing-dont-you" type command line options (2 of them) before it gets to
work. Both need root permissions in a properly set up distribution.
IMO the fact remains, the sd driver is defective in this respect. Locking
up a machine in this rare instance (i.e. changing the block size of an
unmounted disk) is not good.
Doug Gilbert
