smartctl does not work on arbitrary symlinks to devices

[anbe]

$ ln -s /dev/sda /tmp/foo
$ smartctl /tmp/foo
smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, ​http://smartmontools.sourceforge.net

/tmp/foo: Unable to detect device type
...

$ smartctl /dev/sda
# this works fine

$ smartctl -a /dev/block/8:0
# FAIL, as above

$ smartctl /dev/disk/by-path/pci-0000\:00\:1f.2-scsi-0\:0\:0\:0
# this works fine, too

Even if all the links point to /dev/sda, only some of them can be specified as arguments to smartctl - which does not make sence IMHO.

I would expect any symbolic link (which may be nested quite deep) that finally resolves to a device should allow successful execution of smartctl.

In my use case, I have quite a bunch of disks that are used for experiments and switched between machines regularily. Therefore I set up symlinks like /data/dev/disk1 -> /dev/disk/by-id/ABC-123456 with a fixed mapping of the disk$i names and prefer to access the devices via /data/dev/disk$i (and mount them to /data/disk$i) so I don't have to care which /dev/sdX name it currently has (and I don't accidentally access the wrong one - I don't care about the port where it is connected but about the actual physical disk). Using /dev/disk/by-id/ABC-123456 directly is quite cumbersome because they are quite long, look different from vendor to vendor and are not contiguous. UUIDs or something similar is not useful either because the disks get repartitioned and filesystems get recreated regularily. While sfdisk, mkfs, mount, hdparm, ... work in this setup, smartctl does not.

Andreas

[Christian Franke]

Smartctl supports any symlink to a device if the device type is specified, e.g.:

# ln -s /dev/sda /tmp/foo
# smartctl -d sat -a /tmp/foo

If -d TYPE is not specified smartctl tries to guess the device type​ from its path name. The current version does not resolve symlinks except in the /dev/disk/by-* case.

This should be extended such that any symlink works.

[Christian Franke]

r3269.

[Christian Franke]

Please test current SVN if possible.