On 02/01/2014 04:23 PM, "Kai Mäkisara (Kolumbus)" wrote: > > On 1.2.2014, at 16.06, Hannes Reinecke wrote: > >> On 01/31/2014 05:43 PM, Jeremy Linton wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 1/31/2014 2:46 AM, Hannes Reinecke wrote: >>> >>>> This patch make the tape always non-rewinding when SG_IO is used, thus >>>> allowing udev to get a proper device id for tapes. >>> >>> Maybe instead of silently changing the behavior, if you just _HAVE_ to open >>> the st device, add an ioctl or st/mt_op that disables the rewind on close. >>> That way applications have to explicitly disable the rewind on close. >>> >> Okay, that sounds like a better alternative. >> Point is for udev we simply _have_ to use the given device node. >> And when this happens to be set to rewind on close we're doomed. >> > I don’t quite understand why it has to use the auto-rewind device instead of the > non-rewind device. From the minor number it can see what the non-rewind device > is. If the problem is that it is not guaranteed that the non-rewind device exits, you > should rather change the order the devices are created. > This is due to the strictly sequential design udev has. Essentially udev spawns a worker for every device which gets created (= udev receives a uevent for). While udev can and does make sure that all parent devices are created and all events for those device are processed, it _cannot_ make any assumptions about devices at the same level. So when udev spawns a worker for the 'st' device, it is guaranteed that the uevent for the scsi_device has been processed. It is likely that the uevent for the 'nst' device has been received by udev, but it positively impossible to make any assumptions what the udev worker for the 'nst' device may or may not have done. Nor whether it has been processed at all; it might be stuck with some other programs for all we know. So you cannot blindly try to import the values from the 'nst' device; they might not be present at that time. And redirecting the ioctl to another node is possible; that's actually what we did for the old 'scsi_id' program. There we implemented a mechanism to use the 'nst' node instead of the 'st' one for these cases. But we're now trying to deprecate the original (and unmaintained) scsi_id program and replace it with the standard 'sg_inq' program. Which is a standard program which just issues the respective SCSI command; most of the post-processing will be done by udev rules. And implementing the same workaround here is really a bit hackish. Hence this proposal to allow 'sg_inq' (or any program from sg3_utils) to be called without interrupting normal operations on a tape device. > If you absolutely have to do this, then do it. But new ioctls are deprecated and > also it is a bad habit to change the kernel to make things easier for a single > program. > Well, the actual problem here is that the 'st' driver is not designed for multi-initiator environments. The original design for the driver assumed that a single program had control over the 'st' driver, and there is only one instance talking to the hardware. Which simply doesn't fit well with the modern, asynchronous, setup. And it's not just udev which suffers here; try to setup multipath on a tape device ... >> I'll be drafting up a patch. >> > If you do, don’t forget to update the documentation. > Okay. New patch attached. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)