Bug 650107

Created attachment 477765 [details]
Proposed udev rule to add /dev/changer* symlinks

The attached udev rule appears to work fine for me.

(In reply to comment #0)
> ch 10:0:4:0: Attached scsi changer ch0
> ch 10:0:4:0: Attached scsi generic sg6 type 8

hmm... is there a /dev/ch0 which could be used instead?

And you should really use the symbolic link in /dev/disk/*/* which is more precise.

I can see the

...
ch 3:0:8:0: Attached scsi changer ch0
...
ch 3:0:10:0: Attached scsi changer ch1
...

messages in my syslog, but I cannot see any /dev/ch? on my systems:

# ls -ld /dev/ch*
drwxr-xr-x 2 root root 3520 Nov  9 13:15 /dev/char
# 

Which symbolic link in /dev/disk/*/* should I use? It appears there are only disk drives (as the name suggests), but not any tape drives or media changers.

(In reply to comment #4)
> I can see the
> 
> ...
> ch 3:0:8:0: Attached scsi changer ch0
> ...
> ch 3:0:10:0: Attached scsi changer ch1
> ...
> 

ok.. reading the kernel driver, the devices are:

/dev/sch[0-9]

what is the output of:

# scsi_id --export --whitelisted /dev/sch0

There is no output from scsi_id, but the sch* devices do exist:

# scsi_id --export --whitelisted /dev/sch0
# ls -l /dev/sch*
crw-rw---- 1 root disk 86, 0 Nov  9 12:26 /dev/sch0
crw-rw---- 1 root disk 86, 1 Nov  9 12:26 /dev/sch1
#

Note that the /dev/sch* devices are NOT what can be used for example with "mtx":

# ls -l /dev/sch0 /dev/sg10
crw-rw---- 1 root disk 86,  0 Apr  1 22:58 /dev/sch0
crw-rw---- 1 root tape 21, 10 Apr  1 22:58 /dev/sg9
# mtx -f /dev/sch0 status
/dev/sch0 is not an sg device, or old sg driver
# mtx -f /dev/sg10 status
  Storage Changer /dev/sg10:1 Drives, 7 Slots ( 0 Import/Export )
Data Transfer Element 0:Empty
      Storage Element 1:Full 
      Storage Element 2:Empty
      Storage Element 3:Empty
      Storage Element 4:Empty
      Storage Element 5:Empty
      Storage Element 6:Empty
      Storage Element 7:Empty

Same problem here, no devices with

/dev/disk/*/*

but I can find the devices with

/dev/tape/*/*

/dev/tape/by-id/scsi-3500110a001407f36 -> ../../st0
/dev/tape/by-id/scsi-3500110a001407f36-nst -> ../../nst0
/dev/tape/by-id/scsi-3500e09efff0ede6f -> ../../sg4


But 

/dev/changer*

does not exist, I added the rule from comment 1 and this way it works.

Yes, it works, but it is still suboptimal, because standard tools like "mtx"
expect "/dev/changer0" as first (or only) device and thus default, not some
/dev/changer-sgXXX

maybe "mtx" should be rewritten to use /dev/sch[0-9]*

> maybe "mtx" should be rewritten to use /dev/sch[0-9]*

Well, and all other tools that refer to self-explaining device names like /dev/dvd, /dev/dvdrw, /dev/cdrom, /dev/floppy, /dev/tape, ...
should be changed as well?

This doesn't sound like a good idea to me.  Of course, it would solve the problem for you but just by defining it as a SEP (somebody else's problem).

In general it is a bad idea to address a device by it's kernel name, because you cannot be sure, that the numbering stays the same across reboots.

Because of this, we created the /dev/disk/* and /dev/tape/* symlinks.

/lib/udev/rules.d/60-persistent-storage-tape.rules:

# type 8 devices are "Medium Changers"
SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="8", IMPORT{program}="scsi_id --sg-version=3 --export --whitelisted -d $tempnode", SYMLINK+="tape/by-id/scsi-$env{ID_SERIAL}"


maybe we should add to the last rule:

 , SYMLINK+="tape/by-id/$env{ID_BUS}-$env{ID_SERIAL}-changer"

I understand your reasoning, and agree with it for the general case.  But please also consider Joe Average User - they will have only one floppy drive, only one CDROM or DVD drive, only one tape drive at their systems, so numbering will actually be always the same.

Guess if these majority of users like referring to their tapes as
"/dev/tape/by-id/scsi-STANDBERGSLR100_SN100002993-nst" or "/dev/tape/by-path/01.0-scsi-0" when they used to use plain simple names?

And if such changes get implemented and forced on the users, then all tools that refer to the old names and use these as defaults MUST be fixed as well, or you will really frustrate users.

And if you add changes to the tape/by-id/ dir, then please also to tape/by-path/ as well to make it at least consistent.

Thanks.

And another argument: Please keep in mind that Linux is not everything.  The "mtx" tool for example supports "32-bit MS Windows (NT/2000/XP), All BSD Platforms (FreeBSD/NetBSD/OpenBSD/Apple Mac OS X), All POSIX (Linux/BSD/UNIX-like OSes), FreeBSD, Linux, Win2K, Microsoft Windows Server 2003, WinXP, Solaris" so it seems inappropriate to demand changes of the defaults just because Linux decides to rename things.

(In reply to comment #14)
> And another argument: Please keep in mind that Linux is not everything.  The
> "mtx" tool for example supports "32-bit MS Windows (NT/2000/XP), All BSD
> Platforms (FreeBSD/NetBSD/OpenBSD/Apple Mac OS X), All POSIX
> (Linux/BSD/UNIX-like OSes), FreeBSD, Linux, Win2K, Microsoft Windows Server
> 2003, WinXP, Solaris" so it seems inappropriate to demand changes of the
> defaults just because Linux decides to rename things.

Neither of them have a simple /dev/changer* device.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.