From: Nao Nishijima <nao.nishijima.xt@hitachi.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
Greg KH <greg@kroah.com>,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
jcm@redhat.com, hare@suse.de, stefanr@s5r6.in-berlin.de,
yrl.pp-manager.tt@hitachi.com
Subject: Re: [PATCH 1/3] [RFC] genhd: add a new attribute in device structure
Date: Fri, 17 Jun 2011 20:36:38 +0900 [thread overview]
Message-ID: <4DFB3C46.4030909@hitachi.com> (raw)
In-Reply-To: <BANLkTikUNqTxgD_+TTVpcFyRDu_fSesrsg@mail.gmail.com>
Hi Kay,
Thank you for looking at it.
(2011/06/17 2:20), Kay Sievers wrote:
> On Thu, Jun 16, 2011 at 19:09, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> On Thu, Jun 16, 2011 at 18:25, James Bottomley
>> <James.Bottomley@hansenpartnership.com> wrote:
>>> On Thu, 2011-06-16 at 09:14 -0700, Greg KH wrote:
>>>> All userspace naming will be taken care of by the usual udev rules, so
>>>>> for disks, something like /dev/disk/by-preferred/<fred> which would be
>>>>> the usual symbolic link.
>>>>
>>>> No, udev can not create such a link after the preferred name is set, as
>>>> it has no way of knowing that the name was set.
>>>
>>> It can if we trigger a uevent. Note: I'm not advocating this ... I'd be
>>> equally happy having whatever sets the kernel name create the link (or
>>> tickle udev to create it). We definitely require device links, though,
>>> to get this to work.
>
> Guess all that would work now, including mount(8) not canonicalizing.
> What would happen if we mount:
> /dev/disk/by-pretty/foo
> and some tool later thinks the pretty name should better be 'bar', it
> writes the name to /sys, we get a uevent, the old link disappears, we
> get a new link, mount has no device node anymore for the mounted
> device ...
>
> So we basically get a one-shot additional pretty name? Guess, the
> _single_ name changed anytime later just asks for serious problems. We
> need to set it very early to be really useful, but how, where is it
> coming from?
>
If we can avoid serious problems, I will implement preferred name as
write once.
I have two idea for work preferred name from the very first steps during
early boot in initramfs.
1. I think we can provide udev rules for preferred name in initramfs.
2. (option) I consider using user-defined name for the LUNs(*) because
it is possible to get the name in initramfs. The user store preferred
name in LUNs by sg command if available.
(*) Hannes say:
> Well, certain storage arrays are able to print out the user-defined name for the LUNs:
>
> # sg_vpd -p 0xc8 /dev/sdc
> Extended device identification (RDAC) VPD Page:
> Volume Unique Identifier: 60080e50001bf1f0000005004ddb05a4
> Creation Number: 1280, Timestamp: Tue May 24 03:11:00 2011
> Volume User Label: mas-1
> Storage Array Unique Identifier: 60080e50001bf1f0000000004d418973
> Storage Array User Label: LSI-SAS-DIF
> Logical Unit Number: 0000000000000000
>
> where the 'Volume User Label' is the name the administrator has given to the LUN on the storage array.
Thanks,
--
Nao NISHIJIMA
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., YOKOHAMA Research Laboratory
Email: nao.nishijima.xt@hitachi.com
next prev parent reply other threads:[~2011-06-17 11:36 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-15 8:16 [PATCH 0/3] [RFC] Persistent device name using preferred name Nao Nishijima
2011-06-15 8:16 ` [PATCH 1/3] [RFC] genhd: add a new attribute in device structure Nao Nishijima
2011-06-15 14:43 ` James Bottomley
2011-06-15 15:33 ` Greg KH
2011-06-16 12:03 ` Nao Nishijima
2011-06-16 15:41 ` Greg KH
2011-06-16 15:50 ` James Bottomley
2011-06-16 16:14 ` Greg KH
2011-06-16 16:25 ` James Bottomley
2011-06-16 17:09 ` Kay Sievers
2011-06-16 17:20 ` Kay Sievers
2011-06-16 18:00 ` Douglas Gilbert
2011-06-16 18:05 ` Kay Sievers
2011-06-16 18:15 ` Douglas Gilbert
2011-06-16 18:31 ` Kay Sievers
2011-06-16 21:25 ` Stefan Richter
2011-06-17 6:27 ` Hannes Reinecke
2011-06-17 6:27 ` Hannes Reinecke
2011-06-17 12:28 ` Nao Nishijima
2011-06-17 12:28 ` Nao Nishijima
2011-06-17 11:36 ` Nao Nishijima [this message]
2011-06-16 18:19 ` Greg KH
2011-06-16 20:31 ` James Bottomley
2011-06-16 22:05 ` Kay Sievers
2011-06-16 22:45 ` James Bottomley
2011-06-16 23:04 ` Kay Sievers
2011-06-17 11:53 ` Masami Hiramatsu
2011-06-17 14:30 ` Kay Sievers
2011-06-17 14:27 ` James Bottomley
2011-06-17 14:40 ` Kay Sievers
2011-06-17 14:49 ` James Bottomley
2011-06-17 15:39 ` Kay Sievers
2011-06-17 15:39 ` Kay Sievers
2011-06-17 16:12 ` Kay Sievers
2011-06-17 16:22 ` Greg KH
2011-06-18 19:40 ` James Bottomley
2011-06-18 19:55 ` Kay Sievers
2011-06-21 4:51 ` Nao Nishijima
2011-06-21 4:51 ` Nao Nishijima
2011-06-19 1:54 ` Kyle Moffett
2011-06-19 4:14 ` James Bottomley
2011-06-17 6:55 ` Stefan Richter
2011-06-17 5:25 ` Greg KH
2011-06-17 15:41 ` Douglas Gilbert
2011-06-17 15:57 ` Kay Sievers
2011-06-17 3:33 ` Masami Hiramatsu
2011-06-17 5:22 ` Greg KH
2011-06-17 8:15 ` Masami Hiramatsu
2011-06-16 17:32 ` Douglas Gilbert
2011-06-16 18:02 ` Al Viro
2011-06-16 22:48 ` James Bottomley
2011-06-15 8:16 ` [PATCH 2/3] [RFC] sd: print preferred name in kernel messages Nao Nishijima
2011-06-15 8:16 ` [PATCH 3/3] [RFC] fs: print preferred name in procfs messages Nao Nishijima
2011-06-15 15:37 ` [PATCH 0/3] [RFC] Persistent device name using preferred name Greg KH
2011-06-17 5:58 ` Nao Nishijima
2011-06-17 5:58 ` Nao Nishijima
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=4DFB3C46.4030909@hitachi.com \
--to=nao.nishijima.xt@hitachi.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=greg@kroah.com \
--cc=hare@suse.de \
--cc=jcm@redhat.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=stefanr@s5r6.in-berlin.de \
--cc=yrl.pp-manager.tt@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.