All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@suse.de>
To: Hannes Reinecke <hare@suse.de>
Cc: Nao Nishijima <nao.nishijima.xt@hitachi.com>,
	Greg KH <greg@kroah.com>,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-hotplug@vger.kernel.org, Kay Sievers <kay.sievers@vrfy.org>,
	Jon Masters <jcm@redhat.com>,
	2nddept-manager@sdl.hitachi.co.jp
Subject: Re: [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel.
Date: Fri, 08 Apr 2011 08:14:12 -0700	[thread overview]
Message-ID: <1302275652.4090.10.camel@mulgrave.site> (raw)
In-Reply-To: <4D9F1CD1.2020600@suse.de>

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



WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@suse.de>
To: Hannes Reinecke <hare@suse.de>
Cc: Nao Nishijima <nao.nishijima.xt@hitachi.com>,
	Greg KH <greg@kroah.com>,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-hotplug@vger.kernel.org, Kay Sievers <kay.sievers@vrfy.org>,
	Jon Masters <jcm@redhat.com>,
	2nddept-manager@sdl.hitachi.co.jp
Subject: Re: [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel.
Date: Fri, 08 Apr 2011 08:14:12 -0700	[thread overview]
Message-ID: <1302275652.4090.10.camel@mulgrave.site> (raw)
In-Reply-To: <4D9F1CD1.2020600@suse.de>

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-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@suse.de>
To: Hannes Reinecke <hare@suse.de>
Cc: Nao Nishijima <nao.nishijima.xt@hitachi.com>,
	Greg KH <greg@kroah.com>,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-hotplug@vger.kernel.org, Kay Sievers <kay.sievers@vrfy.org>,
	Jon Masters <jcm@redhat.com>,
	2nddept-manager@sdl.hitachi.co.jp
Subject: Re: [PATCH 1/2] SCSI: Add a SCSI option for persistent device
Date: Fri, 08 Apr 2011 15:14:12 +0000	[thread overview]
Message-ID: <1302275652.4090.10.camel@mulgrave.site> (raw)
In-Reply-To: <4D9F1CD1.2020600@suse.de>

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



  reply	other threads:[~2011-04-08 15:14 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-05 12:49 [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel Nao Nishijima
2011-04-05 12:49 ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Nao Nishijima
2011-04-05 12:50 ` [PATCH 2/2] SCSI: modify SCSI subsystem Nao Nishijima
2011-04-05 12:50   ` Nao Nishijima
2011-04-05 16:14 ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel Greg KH
2011-04-05 16:14   ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names Greg KH
2011-04-08 14:12   ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel Nao Nishijima
2011-04-08 14:12     ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names Nao Nishijima
2011-04-08 14:12     ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel Nao Nishijima
2011-04-08 14:33     ` Hannes Reinecke
2011-04-08 14:33       ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names Hannes Reinecke
2011-04-08 14:33       ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel Hannes Reinecke
2011-04-08 15:14       ` James Bottomley [this message]
2011-04-08 15:14         ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device James Bottomley
2011-04-08 15:14         ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel James Bottomley
2011-04-08 16:14         ` Greg KH
2011-04-08 16:14           ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names Greg KH
2011-04-08 16:43           ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel Kay Sievers
2011-04-08 16:43             ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names Kay Sievers
2011-04-08 16:43             ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel Kay Sievers
2011-04-12 13:23         ` Nao Nishijima
2011-04-12 13:23           ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names Nao Nishijima
2011-04-12 13:23           ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel Nao Nishijima
2011-04-12 13:29           ` James Bottomley
2011-04-12 13:29             ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device James Bottomley
2011-04-12 13:29             ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel James Bottomley
2011-04-14  2:06       ` Nao Nishijima
2011-04-14  2:06         ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names Nao Nishijima
2011-04-14  2:06         ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel Nao Nishijima
2011-04-14  2:18         ` Greg KH
2011-04-14  2:18           ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names Greg KH
2011-04-08 17:21     ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel Stefan Richter
2011-04-08 17:21       ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names Stefan Richter
2011-04-18 20:10       ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel Jeremy Linton
2011-04-05 16:14 ` Greg KH
2011-04-05 16:14   ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names Greg KH
2011-04-08 14:07   ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel Nao Nishijima
2011-04-08 14:07     ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names Nao Nishijima
2011-04-08 16:12     ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel Greg KH
2011-04-08 16:12       ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names Greg KH
2011-04-14  8:15       ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel Nao Nishijima
2011-04-14  8:15         ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names Nao Nishijima
2011-04-14  8:15         ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel Nao Nishijima
2011-04-14 20:07         ` Greg KH
2011-04-14 20:07           ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names Greg KH
2011-04-14 20:07           ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1302275652.4090.10.camel@mulgrave.site \
    --to=james.bottomley@suse.de \
    --cc=2nddept-manager@sdl.hitachi.co.jp \
    --cc=greg@kroah.com \
    --cc=hare@suse.de \
    --cc=jcm@redhat.com \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-hotplug@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=nao.nishijima.xt@hitachi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.