Re: [PATCH] st: Do not rewind for SG_IO
On 02/03/2014 10:58 PM, Jeremy Linton wrote: On 2/3/2014 2:51 PM, Kay Sievers wrote: 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. 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 -- Dr. Hannes Reinecke zSeries Storage h...@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) -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
Hannes == Hannes Reinecke h...@suse.de 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... -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
On 02/06/2014 02:21 PM, Martin K. Petersen wrote: Hannes == Hannes Reinecke h...@suse.de 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. Hehe. Beat you to it. My patch provides both the original VPD 0x83 and 0x80 bits 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 ... I'll take a look at your patch later today... Thanks. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@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) -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
Hannes == Hannes Reinecke h...@suse.de writes: My patch provides both the original VPD 0x83 and 0x80 bits 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. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
On Thu, 2014-02-06 at 08:50 -0500, Martin K. Petersen wrote: Hannes == Hannes Reinecke h...@suse.de writes: My patch provides both the original VPD 0x83 and 0x80 bits 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. 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 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. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
On 02/06/2014 03:38 PM, James Bottomley wrote: On Thu, 2014-02-06 at 08:50 -0500, Martin K. Petersen wrote: Hannes == Hannes Reinecke h...@suse.de writes: My patch provides both the original VPD 0x83 and 0x80 bits 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. 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 ... 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 -- Dr. Hannes Reinecke zSeries Storage h...@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) -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
On 14-02-06 10:13 AM, Hannes Reinecke wrote: On 02/06/2014 03:38 PM, James Bottomley wrote: On Thu, 2014-02-06 at 08:50 -0500, Martin K. Petersen wrote: Hannes == Hannes Reinecke h...@suse.de writes: My patch provides both the original VPD 0x83 and 0x80 bits 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. 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 ... 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 ... 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 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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/2/2014 5:42 AM, Hannes Reinecke wrote: 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- -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/03/2014 03:50 PM, Jeremy Linton wrote: On 2/2/2014 5:42 AM, Hannes Reinecke wrote: 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 h...@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) -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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/3/2014 9:06 AM, Hannes Reinecke wrote: 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- -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
On Mon, Feb 3, 2014 at 4:08 PM, Jeremy Linton jlin...@tributary.com wrote: On 2/3/2014 9:06 AM, Hannes Reinecke wrote: 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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
On Mon, 2014-02-03 at 21:51 +0100, Kay Sievers wrote: On Mon, Feb 3, 2014 at 4:08 PM, Jeremy Linton jlin...@tributary.com wrote: On 2/3/2014 9:06 AM, Hannes Reinecke wrote: 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? 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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
On 14-02-03 10:08 AM, Jeremy Linton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/3/2014 9:06 AM, Hannes Reinecke wrote: 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. 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 sti nodes and nsti 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]diskATA INTEL SSDSC2CW12 400i /dev/sda /dev/sg0 [8:0:0:0]tapeLinuxscsi_debug 0004 - /dev/sg1 with the st module loaded and no indication in dmesg. Doug Gilbert -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
On Mon, Feb 3, 2014 at 10:16 PM, Douglas Gilbert dgilb...@interlog.com wrote: On 14-02-03 10:08 AM, Jeremy Linton wrote: 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 sti nodes and nsti 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. 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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
On 2/3/2014 2:51 PM, Kay Sievers wrote: 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. 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. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
On Mon, Feb 3, 2014 at 10:58 PM, Jeremy Linton jlin...@tributary.com wrote: On 2/3/2014 2:51 PM, Kay Sievers wrote: 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. 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. 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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
On 2.2.2014, at 13.42, Hannes Reinecke h...@suse.de wrote: [part of explanation snipped from reply] 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. OK. After your explanation I think adding the new MTIOCTOP operation is the least ugly solution :-) 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. 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. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
On 02/02/2014 08:15 PM, Kai Mäkisara (Kolumbus) wrote: On 2.2.2014, at 13.42, Hannes Reinecke h...@suse.de wrote: [part of explanation snipped from reply] 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. OK. After your explanation I think adding the new MTIOCTOP operation is the least ugly solution :-) Ok. 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. 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. 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? Ok, can do. Let's draft up a new version. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@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) -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
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'll be drafting up a patch. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@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) -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
On 1.2.2014, at 16.06, Hannes Reinecke h...@suse.de 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. 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. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
-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. 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- -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: Do not rewind for SG_IO
-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. -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- -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
