lkml.org 
[lkml]   [2011]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel.
From
Date
On Fri, 2011-04-08 at 07:33 -0700, Hannes Reinecke wrote:
> > The problem I would like to discuss here is that users can not identify
> > a disk from kernel messages when they DIRECTLY refer to these messages.
> > For example, a device name is used instead of a symbolic link names in
> > bootup messages, I/O devices errors and /proc/partitions …etc.
> >
> > In particular, users can not identify an appropriate device from a
> > device name in syslog since different device name may be assigned to it
> > at each boot time.
> >
> > My idea is able to fix this issue with small changes in scsi subsystem.
> > Also, it is implemented as an option. Therefore, it does not affect
> > users who do not select this option.
> >
> We have been discussing this problem several times in the past, and
> indeed on these very mailing list.
>
> The conclusion we arrived at is that the kernel-provided device node
> name is inherently unstable and impossible to fix within the existing
> 'sdX' naming scheme.
> So the choices have been to either move to a totally different naming
> scheme or keep the naming scheme and provide the required information
> by other means.
> We have decided on the latter, and agreed on using udev to provide
> persistent device names.
> We are fully aware that any kernel related messages are subject to
> chance after reboot, but then most kernel related messages are
> (PID number, timestamps, login tty etc).
> And also we are aware that any kernel messages need to be matched
> against the current system layout to figure out any hardware-related
> issue.
>
> But then basically all products requiring to filter out information
> from kernel messages already do so I don't see a problem with that.
>
> Just adding an in-kernel identifier to the LUN will only be an
> incomplete solution, as other identifiers will still be volatile.
>
> So I would prefer by keeping the in-kernel information as small
> as possible to reduce memory consumption and rely on out-of-band
> programs to provide the required mapping.

So, while I agree totally with the above: udev and userspace is the way
to go, I'm not totally opposed to having a non-invasive mechanism for
indicating a user's preferred name for a device. I think there are a
couple of ways to do this:

1. Entirely in userspace: just have udev consult a preferred name
file and create say /dev/disk/by-preferred. Then have all the
tools that normally output device information do the same (i.e.
since real name to preferred name is 1:1, they could all do a
reverse lookup).
2. have a writeable sysfs preferred_name field, either in the
generic device or just in SCSI. The preferred name would be
used by outbound only (i.e. kernel dev_printk messages and
possibly /proc/partitions). All inbound uses of the device
would come via the standard udev mechanisms
(i.e. /dev/disk/by-preferred would be the usual symlink). This
means from the kernel point of view, no renaming has happened.
We'd just try to print out the preferred name in certain
circumstances, which should solve most of the described problem.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2011-04-08 17:17    [W:0.071 / U:1.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site