linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nao Nishijima <nao.nishijima.xt@hitachi.com>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-hotplug@vger.kernel.org, Kay Sievers <kay.sievers@vrfy.org>,
	James Bottomley <James.Bottomley@suse.de>,
	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
Date: Thu, 14 Apr 2011 08:15:36 +0000	[thread overview]
Message-ID: <4DA6AD28.5020604@hitachi.com> (raw)
In-Reply-To: <20110408161212.GA12111@kroah.com>

Hi,

(2011/04/09 1:12), Greg KH wrote:
> On Fri, Apr 08, 2011 at 11:07:41PM +0900, Nao Nishijima wrote:
>> Hi,
>>
>> (2011/04/06 1:14), Greg KH wrote:
>>> On Tue, Apr 05, 2011 at 09:49:46PM +0900, Nao Nishijima wrote:
>>>> This patch series provides a SCSI option for persistent device
>>>> names in kernel. With this option, user can always assign a
>>>> same device name (e.g. sda) to a specific device according to
>>>> udev rules and device id.
>>>>
>>>> Issue:
>>>> Recently, kernel registers block devices in parallel. As a result,
>>>> different device names will be assigned at each boot time. This
>>>> will confuse file-system mounter, thus we usually use persistent
>>>> symbolic links provided by udev. However, dmesg and procfs outputs
>>>> show device names instead of the symbolic link names. This causes
>>>> a serious problem when managing multiple devices (e.g. on a
>>>> large-scale storage), because usually, device errors are output
>>>> with device names on dmesg. We also concern about some commands
>>>> which output device names, as well as kernel messages.
>>>>
>>>> Solution:
>>>> To assign a persistent device name, I create unnamed devices (not
>>>> a block device, but an intermediate device. users cannot read/write
>>>> this device). When scsi device driver finds a LU, the LU is registered
>>>> as an unnamed device and inform to udev. After udev finds the unnamed
>>>> device, udev assigns a persistent device name to a specific device
>>>> according to udev rules and registers it as a block device. Hence,
>>>> this is just a naming, not a renaming.
>>>>
>>>> Some users are satisfied with current udev solution. Therefore, my
>>>> proposal is implemented as an option.
>>>>
>>>> If using this option, add the following kernel parameter.
>>>>
>>>> 	scsi_mod.persistent_name=1
>>>>
>>>> Also, if you want to assign a device name with sda, add the
>>>> following udev rules.
>>>>
>>>> SUBSYSTEM="scsi_unnamed", ATTR{disk_id}="xxx", PROGRAM="/bin/sh
>>>> -c 'echo -n sda > /sys/%p/disk_name'"
>>>
>>> Also, where is the "real" program you have created to properly name
>>> devices from userspace?  You need that to properly test this patch,
>>> right?
>>>
>>
>> In the udev rule described above, notation “xxx” indicated by
>> ATTR(disk_id) is scsi id given by disk. Then, when udev finds this rule,
>> "/bin/sh -c 'echo -n sda>  /sys/%p/disk_name'" indicated by PROGRAM is
>> operated using xxx (scsi id) if udev find the disk with scic id xxx.
>> Thus, persistent device name is assigned.
>>
>> I have tested this patch using the udev rule. and It works well.
> 
> That's nice, but it's a "toy".  What have you used to test this with
> 20000 scsi devices to properly work like it does today?  Where is the
> program that will name them in a deterministic manner?
> 
> We have that functionality today, you can't break it.
> 
> thanks,

Indeed, I have not (can not, of course) tested 20000 scsi devices to
properly work. This feature targets only scsi disk/cdrom/tape devices.
Not all devices. We expect the target users are system administrators
who need to control all devices for maintenance. They know all devices
connected to the server and those devices will tested before connecting.

We expect that admin will enable this option after installation. This
means that device names are assigned by current mechanism when
installation. Admin enables the option and makes udev rules (we are
planning to make shell script which generate udev rules use by-id and
assigned device names). In other word, this feature will be used just
for "fixing" the names.

In our scenario, admin appends a new rule manually when a new LU is
added. In the future, we are planning to enhance udev to append a new
rule automatically as like as NIC.

Thanks,


-- 
Nao NISHIJIMA
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., YOKOHAMA Research  Laboratory
Email: nao.nishijima.xt@hitachi.com

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

Thread overview: 18+ 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 Nao Nishijima
2011-04-05 12:50 ` [PATCH 2/2] SCSI: modify SCSI subsystem Nao Nishijima
2011-04-05 16:14 ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names Greg KH
2011-04-08 14:12   ` Nao Nishijima
2011-04-08 14:33     ` Hannes Reinecke
2011-04-08 15:14       ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device James Bottomley
2011-04-08 16:14         ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names Greg KH
2011-04-08 16:43           ` Kay Sievers
2011-04-12 13:23         ` Nao Nishijima
2011-04-12 13:29           ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device James Bottomley
2011-04-14  2:06       ` [PATCH 1/2] SCSI: Add a SCSI option for persistent device names Nao Nishijima
2011-04-14  2:18         ` Greg KH
2011-04-08 17:21     ` Stefan Richter
2011-04-05 16:14 ` Greg KH
2011-04-08 14:07   ` Nao Nishijima
2011-04-08 16:12     ` Greg KH
2011-04-14  8:15       ` Nao Nishijima [this message]
2011-04-14 20:07         ` 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=4DA6AD28.5020604@hitachi.com \
    --to=nao.nishijima.xt@hitachi.com \
    --cc=2nddept-manager@sdl.hitachi.co.jp \
    --cc=James.Bottomley@suse.de \
    --cc=greg@kroah.com \
    --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 \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).