Doug, > 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. As usual T10 made incorrect assumptions about how general purpose operating systems work (as opposed to array firmware). > 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? Indeed. Because we'll only see errors when something changes enough to cause the drive to actually fail a command. There could still be changes which don't alter the logical block size but would cause problems further up the stack. Like PI vs. no PI, zone write pointers, etc. Also, filesystems and other things on top of the device also depend on the parameters reported in the device topology being correct. So even if sd happened to recover from the surprise logical block size change, you could still see filesystem errors or even memory corruption as a result of bad blocks being read in from a disk that has suddenly been formatted or sanitized. Think swapped out data being paged back in. Ouch! For all intents and purposes the disk is a different device after this type of operation. It is imperative that we treat it as such. > 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. Actually, it's much simpler: sg_format should simply unbind sd from the device before format and bind it after. As far as I'm concerned, that's the only sane approach for format, sanitize, and any passthrough commands that go out and alter fundamental device characteristics behind the kernel's back. >> 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. Not particularly. A good place to start would be to check whether the device is mounted and whether there are any holders for the device and its partitions in sysfs. libblkid may be able to help in this department. Even though root and can clobber things at will, nothing prevents us from being friendly about it. mkfs won't run on a device that's already mounted, for instance. And it asks you politely whether to overwrite if it finds a valid superblock on an unmounted device. -- Martin K. Petersen Oracle Linux Engineering
