st: Do not rewind for SG_IO
Subsystems (3)
PATCH 1/1 st: Do not rewind for SG_IO
Plain 'st' devices are defined to do a rewind on close. This causes quite some issues when trying to read the VPD pages to figure out the WWN of the device. Especially for udev this means we either have to use another (non-rewinding) device node for this (and thereby introducing race conditions) or not generating a persistent device node at all (and breaking multi-tape setups).
This patch make the tape always non-rewinding when SG_IO is used, thus allowing udev to get a proper device id for tapes.
--- drivers/scsi/st.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/scsi/st.c +3 -0
@@ -3645,6 +3645,9 @@ static long st_ioctl(struct file *file, unsigned int cmd_in, unsigned long arg)case SCSI_IOCTL_GET_IDLUN :case SCSI_IOCTL_GET_BUS_NUMBER :break ; +case SG_IO : + STp->rew_at_close =0 ; +/* Fallthrough */ default : if ((cmd_in == SG_IO || cmd_in == SCSI_IOCTL_SEND_COMMAND ||
Signature · 1 line
1.7.12.4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 2 lines · Hannes Reinecke
This patch make the tape always non-rewinding when
SG_IOis used, thus allowing udev to get a proper device id for tapes.
This is wholly bad. Just because someone fires a SG ioctl at the device
(usually to perform an operation that cannot be done with the st_ops) doesn't mean they don't want the tape rewound on close.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJS69EBAAoJEL5i86xrzcy7Ke0IAJbFISKHpJXuuWkK5EveElgG 8+Oy/ndRTSilqg5Ghn4Givr6LnVgs2hZVu6RUz3Y4WADwehxMof3iq6VhqN8bwkr Zun40DxZAwrxAQQJ8jn+0grKbiL/GdkTr6CwVJ7AUC1odFUOXd9tCqKa8YEzsRwQ dfoHBqU3cgGFir/l9wlvz0n+9kR4O3Y81IzCTJNAaLNRDelss6eqKEXuRI/53/5y K5WcYSxHNvqpBLWlRRF2fouyrxiVdsYr4WGoJZf9ReMK5UV8Ztr3YFG7HsRAAyTA b9PzWQF160U73sh6UFIjxG1UNmkBMxilLdQTJWfVHrQTeWakXRIV9gYB/0Z2l2Q= =teWU
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 2 lines · Hannes Reinecke
This patch make the tape always non-rewinding when
SG_IOis 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJS69K7AAoJEL5i86xrzcy7aC8IAJWoag7UaFselARB6eZ4Zfvm qi0Fho04TkqnNUJ5VEU81p05XwPJrmonrmqK55kR0PVkMT3o4Wp/KpkeN7gwrQjx ecR1Ckpoo4Q6n3W/HY06amN6qxLHgwi8RuU9vF7gjRZP4xqW57WRZz1GcuerD94n tF/i2Ajev6ZsdmRSCUN9DDFDR5RNKZ+XmiX3ihx4L1v27I/zMEteO66pDEIRdCoM laJnzsEfh/VNZdLeB3wck5xnW6HVq9YgqtH/oV+2LHeHg/Ji626g5/qsjhaA3YJQ asol8MJsbBGIcaRKEa9EJYy76GVFyCkMLywVFEyN7F9xcFD75P5p2a4siMlYzBc= =7Viv
-----END PGP SIGNATURE-----
Quoted 12 lines · Jeremy Linton
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 2 lines · Hannes Reinecke
This patch make the tape always non-rewinding when
SG_IOis 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'll be drafting up a patch.
Cheers,
Hannes
Signature · 8 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +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) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 9 lines · Hannes Reinecke
Quoted 8 lines · Jeremy Linton
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 2 lines · Hannes Reinecke
This patch make the tape always non-rewinding when
SG_IOis used, thus allowing udev to get a proper device id for tapes.
Quoted 8 lines
Quoted 4 lines
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.
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.
Quoted 2 lines
I'll be drafting up a patch.
If you do, don’t forget to update the documentation.
Thanks,
Kai
P.S. I don’t like the auto-rewind devices at all. But the Unix systems have those and so we also must to have those ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 16 lines · Kai Mäkisara (Kolumbus)
Quoted 13 lines · Hannes Reinecke
Quoted 12 lines · Jeremy Linton
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 2 lines · Hannes Reinecke
This patch make the tape always non-rewinding when
SG_IOis 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.
Quoted 9 lines
Quoted 4 lines
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.
Quoted 4 lines
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 ...
Quoted 4 lines
Quoted 2 lines
I'll be drafting up a patch.
If you do, don’t forget to update the documentation.
Okay. New patch attached.
Cheers,
Hannes
Signature · 4 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +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)
Quoted 1 line
From
6d0f1d306660c645d72f8e1543ce0bebc719f10bMon Sep 17 00:00:00 2001
From: Hannes Reinecke <[email protected]>
Date: Sun, 2 Feb 2014 12:03:09 +0100
Subject: [PATCH] st: Implement MT_ST_NOREWIND option
This patch implements the MT_ST_NOREWIND option to inhibit the rewind on close setting even on normal 'st' devices. With this patch programs like sg_inq can retrieve the device identification without interrupting the current operation.
Documentation/scsi/st.txt +2 -0
@@ -399,6 +399,8 @@ MTSETDRVBUFFER correctly returns transfer residuals MT_ST_DEBUGGING debugging (global; debugging must be compiled into the driver) + MT_ST_NOREWIND disable rewind-on-close even on autorewind + tape devices MT_ST_SETBOOLEANS MT_ST_CLEARBOOLEANS Sets or clears the option bits.
drivers/scsi/st.c +4 -0
@@ -2228,6 +2228,8 @@ static int st_set_options(struct scsi_tape *STp, long options) STp->immediate_filemark = (options &MT_ST_NOWAIT_EOF ) !=0 ; STm->sysv = (options &MT_ST_SYSV ) !=0 ; STp->sili = (options &MT_ST_SILI ) !=0 ; +if (options &MT_ST_NOREWIND ) + STp->rew_at_close =0 ; DEB( debugging = (options & MT_ST_DEBUGGING) != 0; st_log_options(STp, STm, name); ) }else if (code ==MT_ST_SETBOOLEANS || code ==MT_ST_CLEARBOOLEANS ) {
@@ -2263,6 +2265,8 @@ static int st_set_options(struct scsi_tape *STp, long options) STm->sysv = value;if ((options &MT_ST_SILI ) !=0 ) STp->sili = value; +if (value && (options &MT_ST_NOREWIND ) !=0 ) + Stp->rew_at_close =0 ;DEB ( if ((options & MT_ST_DEBUGGING) != 0) debugging = value;
include/uapi/linux/mtio.h +1 -0
@@ -195,6 +195,7 @@ struct mtpos {#define MT_ST_NOWAIT 0x2000#define MT_ST_SILI 0x4000#define MT_ST_NOWAIT_EOF 0x8000 +#define MT_ST_NOREWIND 0x10000/* The mode parameters to be controlled. Parameter chosen with bits 20-28 */ #define MT_ST_CLEAR_DEFAULT 0xfffff
On 2.2.2014, at 13.42, Hannes Reinecke <[email protected]> wrote:
[part of explanation snipped from reply]
Quoted 7 lines
But we're now trying to deprecate the original (and unmaintained)
scsi_idprogram 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 fromsg3_utils)
to be called without interrupting normal operations on a tape device.
OK. After your explanation I think adding the new MTIOCTOP operation is the least ugly solution :-)
Quoted 7 lines
Quoted 4 lines
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.
The basic problem is that a sequential access device does not fit well the asynchronous setup. I admit that some simplifications have been made because of this.
Quoted 8 lines
And it's not just udev which suffers here; try to setup multipath on a tape device ...
Quoted 4 lines
Quoted 2 lines
I'll be drafting up a patch.
If you do, don’t forget to update the documentation.
Okay. New patch attached.
I think you have not compiled the patched st.c:
@@ -2263,6 +2265,8 @@ static int st_set_options(struct scsi_tape *STp, long options)
STm->sysv = value;
if ((options & MT_ST_SILI) != 0)
STp->sili = value;
+ if (value && (options & MT_ST_NOREWIND) != 0)
+ Stp->rew_at_close = 0;
^^^Should be STp.
However, looking at the code already suggests that this operation does not belong to MT_ST_*. These bits set/clear options that persist. The operations you need is transient so that the effect disappears when the device is closed. I think it would be better to define it as and ordinary MTIOCTOP operation code, e.g., in mtio.h:
#define MTNOAUTOREWIND 36 /* suppress possible pending automatic rewind */
or something like that?
Thanks,
Kai
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 13 lines · Kai Mäkisara (Kolumbus)
On 2.2.2014, at 13.42, Hannes Reinecke <[email protected]> wrote:
[part of explanation snipped from reply]
Quoted 8 lines
But we're now trying to deprecate the original (and unmaintained)
scsi_idprogram 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 fromsg3_utils) to be called without interrupting normal operations on a tape device.
Quoted 3 lines
OK. After your explanation I think adding the new MTIOCTOP operation is the least ugly solution :-)
Ok.
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
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
Quoted 1 line
Quoted 1 line
that a single program had control over the 'st' driver, and there
is only
Quoted 5 lines
Quoted 3 lines
one instance talking to the hardware.
Which simply doesn't fit well with the modern, asynchronous, setup.The basic problem is that a sequential access device does not fit well the asynchronous setup. I admit that some simplifications have been
made because of this.
Quoted 20 lines
Quoted 9 lines
And it's not just udev which suffers here; try to setup multipath on a tape device ...
Quoted 4 lines
Quoted 2 lines
I'll be drafting up a patch.
If you do, don’t forget to update the documentation.
Okay. New patch attached.
I think you have not compiled the patched
st.c:drivers/scsi/st.c +2
-0@@ -2263,6 +2265,8 @@ static int st_set_options(struct scsi_tape *STp, long options) STm->sysv = value;if ((options &MT_ST_SILI ) !=0 ) STp->sili = value; +if (value && (options &MT_ST_NOREWIND ) !=0 ) + Stp->rew_at_close =0 ; ^^^Should be STp.
Quoted 2 lines
However, looking at the code already suggests that this operation does not belong to MT_ST_*. These bits set/clear options that persist. The operations you need
is transient so that the
Quoted 1 line
effect disappears when the device is closed. I think it would be
better to define it as and
Quoted 6 lines
ordinary MTIOCTOP operation code, e.g., in
mtio.h:#define MTNOAUTOREWIND 36 /* suppress possible pending automatic rewind */
or something like that?
Ok, can do.
Let's draft up a new version.
Cheers,
Hannes
Signature · 8 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +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) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 3 lines · Hannes Reinecke
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).
The part I fail to see in this explanation is why the nst/st/st*a/st*m/etc
handles are being treated as separate devices. They aren't. They are all the same physical tape device, so why are the nst devices being handled separately from the st ones?
Maybe the problem is that you have to many "workers" for the tape device.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJS76ykAAoJEL5i86xrzcy7MKMH/0upLuOBOJWzdOfKYq0WmIvZ eIaaZG2vhckYeS2zZtim5uVFQDp5eTOirmjxfwSGzSTSAmNrQJwzZvBO/vA2/Kqk wZSKXp/ZGZhw11+6Kg8f1EArQQwT/i3R6BKglLELFvZVvNOUg3KCnd6nE/4k7ysh H3f6+6/Jb1wUA6h7a65BG7VBQlJ3HqVe01vYTrkb3eYW7IWfN0tX2FMdqYt2zon2 Yo6TRxhTE/dmqJhg8nLB+fA8rUwW7CYU/IX8nsKNn9lPaDdoJ6g22ozpJRrtEZZ+ lt/qL3VxfWu38z0GWhuKuOqY969bMlyaphY7bOgf7LY4osiC7OgarVoxSIgfP9E= =pIPt
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 10 lines · Jeremy Linton
Quoted 3 lines · Hannes Reinecke
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).
The part I fail to see in this explanation is why the
nst/st/st*a/st*m/etc handles are being treated as separate devices. They aren't. They are all the same physical tape device, so why are the nst devices being handled separately from the st ones?
That's due to udev.
Udev is getting events for each device it should create a device node for.
So for 'st' it'll get a series of events for 'stX', and another series of
events for 'nstX'.
Udev will treat each of these events separately, with distinct worker programs handling them. Each of those workers run fully asynchronous and cannot access information from other workers.
Udev cannot and should not make assumptions about any correlations between events; if you need this then you have to explicitly gate events via the 'collect' mechanism.
But even then you can only access information from the currently running
process/event; you cannot modify information from prior events.
So when trying to generate unique IDs for tape devices you either have to
a) modify the program generating the Unique ID to redirect the call to a different device node
or
b) to modify the driver to not rewind the tape
We tried approach a) when using the scsi_id program. But as this program
is rather old and doesn't have a maintainer I'm working on using 'sg_inq' as a replacement. And these kind of hacks really do not belong in a generic program.
(It would involve create a temporary device node, call SG_IO on that, and remove the temporary device node again).
So now we're shooting for b).
Unless you have a better idea ...
Cheers,
Hannes
- --
Dr. Hannes Reinecke zSeries & Storage
[email protected] +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) -----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJS77BsAAoJEGz4yi9OyKjPQz8P/1cY+k9KtEezXC2ovuzJmy9T BjQaoxcTgHbaXykFyEoJeiNQ09XrjAl7IlVOOF9jX3XqC4kYQiBZCThUnC8O3D69 vaZrA6+VR9AoTXbfNzBUdHzEKWTlz5X2ThLzrLPogXS6v5hiw0iBcLq5mvlJxlkc DBHJrV+ujlKOM/JibNwUNldeYAFnrrzCCH50arJ/Eqa6BcLZ2uXTksACqIVybUoI nW1yfVzJdsxI5YwPp0N5bnuAPIg3N7zBTcFCVYqTHUiAmrS4HYkHRrC501yuopCA PS9Gv1KznctEIGudoP5S0Lwn+g/aVSuzOTpo3uUWAa1BNyyvRMRUSzSIUfm2WdAj +o1mswhhX6NZMM9rFrM35dbiky2Nv/pvc2zcD4pvizsLiHkoQER7GQ9FCaBNXP7d eK0OF2jJeEPV6LSC97wxH27Vybv/c89wp0HGDaJc+kd8+WZFIvkLbvY7K3BSA2ut YvuebI59veIYNZEJVEdAGYQ3IEUG8uukbdpqf3Kdr17PQEms/gTW+xYWPo1+hBR7 V58ojgghBxPdVwGRyiSgKgjY/vHLFunm9H83LDrHKdQsKs8JGiTCflPhJEMwwsDo mhlmd5Ihw20Cyh46sd3Uu1onH0L5Rg0hfDqT913ShUFYi5Y+XvtHEezYn73OxYDr JoUo9HYfT843MabEympC
=c45s
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 6 lines · Hannes Reinecke
That's due to udev. Udev is getting events for each device it should create a device node for. So for 'st' it'll get a series of events for 'stX', and another series of events for 'nstX'. Udev will treat each of these events separately, with distinct worker programs handling them. Each of those workers run fully asynchronous and cannot access information from other workers.
So whats wrong with the simple solution? You throw the ones for st away, and
create the st handles from the nst worker.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJS77DnAAoJEL5i86xrzcy7j+cH/24oncr+DN1yZ4ReXk3i8QHx LpI83UgP9EAvvcHJb5Op3IQtojccda1rYmecMS8qLYV0IX33lJg6UXbhkNS/skkR gFbPdsD/27JqJZvCU02U+ET0zfO5XH833UCRKOsqoA/GMeikLAaUKPV5t65eyCHh Qy4CYr4Gve9AxMhV9n00IdadOL5NoH/aO+Qb916zeJ2dUng5TUDqQ3WzdlQQdhD5 ObReHBnTBXlsWQdZL2VakP6gEX2ijiZ09GOIeSf1rKz/974OAudmzLsVjF4BwqTA 5JzqQXezYO2CZ8zkiuCCuiuXEwjv3f62rCuqzi5lQByFGDpvJNMZDAU9GjTn9Z8= =ELYk
-----END PGP SIGNATURE-----
Quoted 11 lines · Jeremy Linton
Quoted 6 lines · Hannes Reinecke
That's due to udev. Udev is getting events for each device it should create a device node for. So for 'st' it'll get a series of events for 'stX', and another series of events for 'nstX'. Udev will treat each of these events separately, with distinct worker programs handling them. Each of those workers run fully asynchronous and cannot access information from other workers.
So whats wrong with the simple solution? You throw the ones for st away, and
create the st handles from the nst worker.
This is not simple and not going to happen. Sibling devices in /sys cannot have a relationship in udev, there are only parent/child dependencies.
Hannes, can't you just drop the weird auto-rewinding device matches from the persistent rules, is that really useful today?
Kay
Quoted 13 lines · Kay Sievers
Quoted 11 lines · Jeremy Linton
Quoted 6 lines · Hannes Reinecke
That's due to udev. Udev is getting events for each device it should create a device node for. So for 'st' it'll get a series of events for 'stX', and another series of events for 'nstX'. Udev will treat each of these events separately, with distinct worker programs handling them. Each of those workers run fully asynchronous and cannot access information from other workers.
So whats wrong with the simple solution? You throw the ones for st away, and
create the st handles from the nst worker.
Quoted 6 lines
This is not simple and not going to happen. Sibling devices in /sys cannot have a relationship in udev, there are only parent/child dependencies.
Hannes, can't you just drop the weird auto-rewinding device matches from the persistent rules, is that really useful today?
Regardless of the outcome of these discussions about adding a rewind ioctl, we can't just kill the auto-rewind devices because that would be an ABI break (the consequence would be people's backup scripts would break and nothing annoys sysadmins more than failed backups).
James
Quoted 2 lines · Kay Sievers
This is not simple and not going to happen. Sibling devices in /sys cannot have a relationship in udev, there are only parent/child dependencies.
Ok.. so if we can't ignore all the "spare" device nodes in a given /sys entry
for a given device. Why open the device to scan it?
I've often wondered why the serial number isn't part of the data in /sys
along with the manufacture/model. The last tape drive I saw that failed to respond to inquiry page 0x80 was over a decade ago (probably manufactured in the early 90s). So enabling it just for tape is pretty safe.
Matching Manufacturer/model/serial is going to be better than anything your
going to get out of 0x83 anyway. That data is guaranteed to be there, but its also guaranteed to be unreliable (every device, and every port has a slightly different set of descriptors they choose to support).
Plus, your not going to have issues accidentally rewinding a device, or
resetting a tape density, or accidentally turning compression off if you don't open the device.
Quoted 2 lines
Hannes, can't you just drop the weird auto-rewinding device matches from the persistent rules, is that really useful today?
The relationship between the st and nst devices is leveraged by a large
number of backup applications in the field. If you change it, its likely lots of breakage will ensue.
Quoted 13 lines · Jeremy Linton
Quoted 2 lines · Kay Sievers
This is not simple and not going to happen. Sibling devices in /sys cannot have a relationship in udev, there are only parent/child dependencies.
Ok.. so if we can't ignore all the "spare" device nodes in a given /sys entry
for a given device. Why open the device to scan it?I've often wondered why the serial number isn't part of the data in /sys
along with the manufacture/model. The last tape drive I saw that failed to respond to inquiry page0x80was over a decade ago (probably manufactured in the early 90s). So enabling it just for tape is pretty safe.
Quoted 8 lines
Matching Manufacturer/model/serial is going to be better than anything your
going to get out of0x83anyway. That data is guaranteed to be there, but its also guaranteed to be unreliable (every device, and every port has a slightly different set of descriptors they choose to support).Plus, your not going to have issues accidentally rewinding a device, or
resetting a tape density, or accidentally turning compression off if you don't open the device.
Well, the predictable symlink for tapes stuff is all pretty old, and got through quite a few changes over the years. Not sure how much the /dev/tape/by-*/ links are really used in the field, and what people really expect here.
(Mis-)using one of the various open() flags which do not make sense for SG_IO or tapes, which would prevent any state changes still sounds like the most convincing option to me. In the end it's always the nicer interface if the device node itself can be used to identify the device, instead of jumping through /sys or adding more proping caches to the kernel.
Quoted 6 lines
Quoted 2 lines
Hannes, can't you just drop the weird auto-rewinding device matches from the persistent rules, is that really useful today?
The relationship between the st and nst devices is leveraged by a large
number of backup applications in the field. If you change it, its likely lots of breakage will ensue.
Sure, but do they really expect the additional symlinks udev creates? We are not talking about the primary device nodes, only about the additional /dev/tape/by-*/ links.
Kay
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 3 lines · Kay Sievers
got through quite a few changes over the years. Not sure how much the
/dev/tape/by-*/links are really used in the field, and what people really expect here.
I'm not sure they actually work that much either (random opensuse 12.3 machine).
lrwxrwxrwx 1 root root 9 Feb 3 15:31 /dev/tape/by-id/scsi-3201034d7b4000007
- -> ../../st3
lrwxrwxrwx 1 root root 10 Feb 3 15:31 /dev/tape/by-id/scsi-3201034d7b4000007-nst -> ../../nst1
That is what shows up on my machine with 4 tape drives /dev/st0->st4. Its because there are 4 devices with the same I_T and different luns. The /dev/st* and /dev/nst* are correct.
Quoted 3 lines
Sure, but do they really expect the additional symlinks udev creates? We are not talking about the primary device nodes, only about the additional
/dev/tape/by-*/links.
Oh... I suspect your right. If anyone is using it is probably one off scripts.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJS8BeoAAoJEL5i86xrzcy7wBkH/jn9wewZIU7DrVRLc0OiHTDh Cm7Fo4wir01i8t29P+qL3EgsMzoe7w3xfCJ74rRks5UO5Vl13NmI0ck3rJ+ElTf7 9MJl40cgQgYB+ATCMy91mcObr6KTwkRI1n1oZZKV8YAd20mGSDIEv9FeqHGEWOC4 c3THh+6C0Fb63cYQ6X3oyK8twHNJl8HAJPRbnZ0oKdvSFdoAGBXoBxQ7mbsaWBcI HkTF6ArHdIMGMeI4F1PUROKMsSeEhwzudvJY3+fb7pQO3pmG6aFTCTVlkSZiDVNX uqhbB9cdz6c0GYHVg/3jCEsmdzMmlT/qY0jy6NChBPgdFpsS1CAfbnYW2eKtpS4= =ANj0
-----END PGP SIGNATURE-----
Quoted 13 lines · Jeremy Linton
Quoted 2 lines · Kay Sievers
This is not simple and not going to happen. Sibling devices in /sys cannot have a relationship in udev, there are only parent/child dependencies.
Ok.. so if we can't ignore all the "spare" device nodes in a given /sys entry
for a given device. Why open the device to scan it?I've often wondered why the serial number isn't part of the data in /sys
along with the manufacture/model. The last tape drive I saw that failed to respond to inquiry page0x80was over a decade ago (probably manufactured in the early 90s). So enabling it just for tape is pretty safe.
Quoted 9 lines
Matching Manufacturer/model/serial is going to be better than anything your
going to get out of0x83anyway. That data is guaranteed to be there, but its also guaranteed to be unreliable (every device, and every port has a slightly different set of descriptors they choose to support).Plus, your not going to have issues accidentally rewinding a device, or
resetting a tape density, or accidentally turning compression off if you don't open the device.
And indeed, I have been wondering about this, too.
And (again) it is something which has been on my To-Do list for a long time.
Moving EVPD page 0x83 (and maybe 0x80, too) into sysfs will save quite a lot of headache we have currently; udev won't have to call 'sg_inq', information will be present even though the device itself might be temporarily unavailable yadda yadda.
So I've decided to bite the bullet and sent out a patch, check for 'Add EVPD page 0x83 entries to sysfs'.
Reviews are welcome.
Cheers,
Hannes
Signature · 8 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +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) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Hannes" == Hannes Reinecke <[email protected]> writes:
Hannes> Moving EVPD page 0x83 (and maybe 0x80, too) into sysfs will save Hannes> quite a lot of headache we have currently; udev won't have to Hannes> call 'sg_inq', information will be present even though the Hannes> device itself might be temporarily unavailable yadda yadda.
Hannes> So I've decided to bite the bullet and sent out a patch, check Hannes> for 'Add EVPD page 0x83 entries to sysfs'.
I'm already doing something similar since I need it for xcopy.
My patch provides both the original VPD 0x83 and 0x80 bits as well as a handle identical to /sbin/scsi_id.
I'll take a look at your patch later today...
Signature · 1 line
Martin K. Petersen Oracle Linux Engineering
Quoted 7 lines · Martin K. Petersen
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Hannes" == Hannes Reinecke <[email protected]> writes:
Hannes> Moving EVPD page
0x83(and maybe0x80, too) into sysfs will save Hannes> quite a lot of headache we have currently; udev won't have to Hannes> call 'sg_inq', information will be present even though the Hannes> device itself might be temporarily unavailable yadda yadda.
Quoted 5 lines
Hannes> So I've decided to bite the bullet and sent out a patch, check Hannes> for 'Add EVPD page
0x83entries to sysfs'.I'm already doing something similar since I need it for xcopy.
Hehe. Beat you to it.
Quoted 3 lines
My patch provides both the original VPD
0x83and0x80bits as well as a handle identical to/sbin/scsi_id.
Bah, don't do that.
That should better be handled by udev rules.
I've got a set of patches moving from scsi_id to sg_inq, which can be easily adapted to using sysfs directly.
Once we figure out if that's the direction we want to go ...
Quoted 2 lines
I'll take a look at your patch later today...
Thanks.
Cheers,
Hannes
Signature · 8 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +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) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Hannes" == Hannes Reinecke <[email protected]> writes:
My patch provides both the original VPD
0x83and0x80bits as well as a handle identical to/sbin/scsi_id.
Hannes> Bah, don't do that. That should better be handled by udev Hannes> rules. I've got a set of patches moving from scsi_id to sg_inq, Hannes> which can be easily adapted to using sysfs directly.
I just want to get out of the "userland sending random SCSI commands" business. That is a world of pain right now.
I wanted to provide a handle that was guaranteed to be compatible with existing tooling. If you have worked around that in udev rules I guess that's OK with me.
Signature · 1 line
Martin K. Petersen Oracle Linux Engineering
Quoted 11 lines · Martin K. Petersen
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Hannes" == Hannes Reinecke <[email protected]> writes:
My patch provides both the original VPD
0x83and0x80bits as well as a handle identical to/sbin/scsi_id.Hannes> Bah, don't do that. That should better be handled by udev Hannes> rules. I've got a set of patches moving from
scsi_idtosg_inq, Hannes> which can be easily adapted to using sysfs directly.I just want to get out of the "userland sending random SCSI commands" business. That is a world of pain right now.
Well, in the words of Bill Clinton "I feel your pain". However, I need to know we won't pick up that same whole world of pain in the kernel. Remember it's not just SCSI devices, it's also ATA devices and potentially other block devices ... then there's blkid and all the weird things it does. Then there's transport identifiers for multi-path reservations and so on.
Convince me this path won't have us shifting a whole bunch of weird from user space to the kernel without any reduction in the weird factor. Remember the point is not what can we do for all the nicely behaved SCSI-3 devices, it's what do we do for everything.
James
Quoted 4 lines
I wanted to provide a handle that was guaranteed to be compatible with existing tooling. If you have worked around that in udev rules I guess that's OK with me.
Quoted 13 lines · James Bottomley
Quoted 11 lines · Martin K. Petersen
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Hannes" == Hannes Reinecke <[email protected]> writes:
My patch provides both the original VPD
0x83and0x80bits as well as a handle identical to/sbin/scsi_id.Hannes> Bah, don't do that. That should better be handled by udev Hannes> rules. I've got a set of patches moving from
scsi_idtosg_inq, Hannes> which can be easily adapted to using sysfs directly.I just want to get out of the "userland sending random SCSI commands" business. That is a world of pain right now.
Quoted 7 lines
Well, in the words of Bill Clinton "I feel your pain". However, I need to know we won't pick up that same whole world of pain in the kernel. Remember it's not just SCSI devices, it's also ATA devices and potentially other block devices ... then there's blkid and all the weird things it does. Then there's transport identifiers for multi-path reservations and so on.
blkid is actually not so bad, _if_ it would distinguish between 'metadata not found' and 'I/O error during metadata read'. I made a patch which hopefully should find it's way upstream.
And blkid just issues plain READ commands, so _this_ behaviour won't change ...
Quoted 5 lines
Convince me this path won't have us shifting a whole bunch of weird from user space to the kernel without any reduction in the weird factor. Remember the point is not what can we do for all the nicely behaved SCSI-3 devices, it's what do we do for everything.
Well, first and foremost the patch should be limited to SCSI-3 (and later devices). So we'd be insulated from the most obvious crap.
So that leaves only devices which claim to be SCSI-3 or something, but still keel over when asked for VPD pages.
However, this type of devices will fail already, as 'sd.c' is already asking for all sorts of VPD pages.
Which leaves only non-Disk devices, but those tend to have a better SCSI implementation as you can't make quick bucks with, say, as SCSI Enclosure device.
But the prime motivator behind this patch is that we can be reasonably sure the device will answer at all.
When retrieving the EVPD pages from userspace you always have the problem that the device might have gone away or being unresponsive by the time you get around sending the SG_IO call.
So you always have these stuck user-space processes asking for information which _had_ been present at one point. In particular udev is prone for this; anyone who ever came across the message
udevd[]: worker unexpectedly returned with status 0x0100
knows what I'm talking about ...
And the more udev events for a device you get, the higher the likelyhood for this to happen is.
Plus I could re-use this information for my scsi_dh_alua patchset, and for xcopy and friends we'll be needing it, too.
Cheers,
Hannes
Signature · 8 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +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) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 53 lines · Hannes Reinecke
Quoted 13 lines · James Bottomley
Quoted 11 lines · Martin K. Petersen
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Hannes" == Hannes Reinecke <[email protected]> writes:
My patch provides both the original VPD
0x83and0x80bits as well as a handle identical to/sbin/scsi_id.Hannes> Bah, don't do that. That should better be handled by udev Hannes> rules. I've got a set of patches moving from
scsi_idtosg_inq, Hannes> which can be easily adapted to using sysfs directly.I just want to get out of the "userland sending random SCSI commands" business. That is a world of pain right now.
Quoted 7 lines
Well, in the words of Bill Clinton "I feel your pain". However, I need to know we won't pick up that same whole world of pain in the kernel. Remember it's not just SCSI devices, it's also ATA devices and potentially other block devices ... then there's blkid and all the weird things it does. Then there's transport identifiers for multi-path reservations and so on.
blkid is actually not so bad, _if_ it would distinguish between 'metadata not found' and 'I/O error during metadata read'. I made a patch which hopefully should find it's way upstream.
And blkid just issues plain READ commands, so _this_ behaviour won't change ...
Quoted 5 lines
Convince me this path won't have us shifting a whole bunch of weird from user space to the kernel without any reduction in the weird factor. Remember the point is not what can we do for all the nicely behaved SCSI-3 devices, it's what do we do for everything.
Well, first and foremost the patch should be limited to SCSI-3 (and later devices). So we'd be insulated from the most obvious crap.
So that leaves only devices which claim to be SCSI-3 or something, but still keel over when asked for VPD pages.
However, this type of devices will fail already, as 'sd.c' is already asking for all sorts of VPD pages.
Which leaves only non-Disk devices, but those tend to have a better SCSI implementation as you can't make quick bucks with, say, as SCSI Enclosure device.But the prime motivator behind this patch is that we can be reasonably sure the device will answer at all.
When retrieving the EVPD pages from userspace you always have the problem that the device might have gone away or being unresponsive by the time you get around sending theSG_IOcall.
So you always have these stuck user-space processes asking for information which _had_ been present at one point. In particular udev is prone for this; anyone who ever came across the message
Quoted 3 lines
udevd[]: worker unexpectedly returned with status
0x0100knows what I'm talking about ...
Running a small array with an external power supply which is insufficient for the task of spinning up more than 1 or 2 disks is interesting to watch :-)
Doug Gilbert
Quoted 10 lines
And the more udev events for a device you get, the higher the likelyhood for this to happen is.
Plus I could re-use this information for my
scsi_dh_aluapatchset, and for xcopy and friends we'll be needing it, too.Cheers,
Hannes
Quoted 12 lines · Jeremy Linton
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 6 lines · Hannes Reinecke
That's due to udev. Udev is getting events for each device it should create a device node for. So for 'st' it'll get a series of events for 'stX', and another series of events for 'nstX'. Udev will treat each of these events separately, with distinct worker programs handling them. Each of those workers run fully asynchronous and cannot access information from other workers.
Quoted 2 lines
So whats wrong with the simple solution? You throw the ones for st away, and
create the st handles from the nst worker.
Doesn't seem to be any good solutions to this problem. If you can't discovery something without modifying its state, then what? For udev and/or sg_inq to know about the special relationship between st<i> nodes and nst<i> nodes seems unreasonable IMO.
The cleanest way I can think of is for the st driver to show this relationship via sysfs. But then why should udev going mining for that relationship? A sysfs flag from the st driver indicating a node is "undiscoverable" might be a start.
A possible hack inside the st driver is to notice that only the SG_IO ioctl is called on a file handle between st_open(/dev/st*, O_RDONLY|O_NONBLOCK) and st_release() then not auto-rewind it.
BTW Recent versions of sg_inq in Linux use open(<dev>, O_RDONLY|O_NONBLOCK) unless 'sg_inq --block=1' is given in which case open(<dev>, O_RDONLY) is used.
I just noticed that when scsi_debug makes a tape device, the st driver silently ignores it, probably because scsi_debug doesn't support a SSC command that st expects it to respond to. IMO the st driver should make some noise if it ever ignores a SCSI device with a PDT of 1 (i.e. a tape).
For example:
# lsscsi -g [0:0:0:0] disk ATA INTEL SSDSC2CW12 400i /dev/sda /dev/sg0 [8:0:0:0] tape Linux scsi_debug 0004 - /dev/sg1
with the st module loaded and no indication in dmesg.
Doug Gilbert
Quoted 14 lines · Douglas Gilbert
Quoted 3 lines · Jeremy Linton
So whats wrong with the simple solution? You throw the ones for st
away, and
create the st handles from the nst worker.Doesn't seem to be any good solutions to this problem. If you can't discovery something without modifying its state, then what? For udev and/or
sg_inqto know about the special relationship between st<i> nodes and nst<i> nodes seems unreasonable IMO.
Quoted 5 lines
The cleanest way I can think of is for the st driver to show this relationship via sysfs. But then why should udev going mining for that relationship? A sysfs flag from the st driver indicating a node is "undiscoverable" might be a start.
Udev rules explicitely match on device names, that should be fine. It can just not be included in the match if it does not provide the needed functionality, or if it is not needed.
Kay