From: Nao Nishijima <nao.nishijima.xt@hitachi.com>
To: Greg KH <greg@kroah.com>
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
James.Bottomley@HansenPartnership.com, kay.sievers@vrfy.org,
jcm@redhat.com, hare@suse.de, stefanr@s5r6.in-berlin.de,
yrl.pp-manager.tt@hitachi.com
Subject: Re: [PATCH 0/3] [RFC] Persistent device name using preferred name
Date: Fri, 17 Jun 2011 14:58:10 +0900 [thread overview]
Message-ID: <4DFAECF2.9060105@hitachi.com> (raw)
In-Reply-To: <20110615153711.GB10160@kroah.com>
Hi Greg,
(2011/06/16 0:37), Greg KH wrote:
> On Wed, Jun 15, 2011 at 05:16:10PM +0900, Nao Nishijima wrote:
>> Hi,
>>
>> This patch series provides preferred name into kernel and procfs
>> messages. Preferred name is user's preferred name for a device.
>>
>> The purpose of this feature is to solve the persistent device
>> naming issues which was discussed here:
>>
>> http://marc.info/?l=linux-scsi&m=130200794615884&w=2
>>
>> There are four issues.
>> 1. kernel messages doesn't show persistent device names
>
> That is because a persistent device name could be anything, there are
> multiple ways of defining a device, and the kernel will not know them
> all as multiple ones could be in use for the same device.
>
Right, thus I'd like to solve it by assigning a unique preferred name
to each device. I mean, user of preferred name will decide to use one
way of defining a device, then kernel can show the name as a persistent
name for him. Since this is completely based on user's choice/decision,
no one will complain about that.
>> 2. procfs messages doesn't show persistent device names
>
> See above.
>
>> 3. Some commands didn't support persistent device name in arguments
>
> Then fix the commands!
>
Yes, of course. I'd like to fix those commands to accept preferred names.
> Seriously, this could be done by now, it's been over a year since this
> was first discussed. All distros could have the updated packages by now
> and this would not be an issue.
>
> I still think this is the correct way to solve the problem as it is a
> userspace issue, not a kernel one.
>
Agreed. In #3 and #4, I don't think it can solve in kernel space now.
>> 4. Some commands message didn't show persistent device names
>
> Same as #3.
>
Yeah. Again, I've changed my mind, I'll try to fix those commands.
>> Then I suggested the intermediate device naming which changes
>> the naming scheme, but it was rejected. I realized that we should
>> use udev to provide persistent device names instead of change the
>> naming scheme.
>
> Yes.
>
>> In LKML discussion, a new idea was suggested by James Bottomley.
>> This idea allows kernel messages show preferred names by adding a
>> new attribute to a device, kernel messages show this new attribute.
>> This idea's advantage is not to change the current naming scheme.
>>
>> I tried implementation of preferred name, and then there are two
>> discussion points.
>>
>> (a) Which devices need support?
>> Preferred name is stored in struct device. Therefore it is available
>> for all devices if we make preferred name support with other device
>> types.
>>
>> This patch series only support scsi block device. Is there the device
>> which needs support? (e.g. Ntwork devices, generic SCSI devices, etc.)
>>
>> (b) What kind of procfs form is good?
>> I implemented preferred name something like this,
>>
>> (preferred name assigned foo to sda)
>> #cat /proc/partitions
>> major minor #blocks name
>>
>> 8 0 488386584 foo
>> 8 1 194560 foo1
>> ...
>>
>> Do you needs device name filed?
>> Something like this,
>>
>> (preferred name assigned foo to sda)
>> #cat /proc/partitions
>> major minor #blocks name preferred
>>
>> 8 0 488386584 sda foo
>> 8 1 194560 sda1 foo1
>> ...
>
> Sorry, but you can not change the format of procfs files without
> breaking a lot of tools, that's no longer allowed.
>
OK, I would not change the format of procfs files.
>> Issue 3 and 4 is command releated issue. Commands have to be
>> modified to use preferred name. We need to create library for
>> preferred name.
>
> Again, this is quite simple and could have been finished by now :(
>
:(
>> Our goal is to solve those issues, and users can use and see
>> preferred name anywhere.
>
> I don't see how your proposed solution would solve the issue of
> userspace using different persistant names for the same device. How
> would it know which one is correct?
>
My proposal don't use current persistent device names for access. Those
are used in a udev rule as information to identify a device. Something
like this:
(Example: using by-id)
SUBSYSTEM=="block",
ENV{ID_SERIAL}=="scsi-SATA_WDC_WD5000AAKS-_WD-WCASY6088049",
SYMLINK+="disk/by-preferred/foo", PROGRAM=”write_preferred_name %p foo”
To access a device from by-preferred persistently, I create new symbolic
link from /dev/disk/by-preferred/foo to /dev/sdX.
> Again, this is a userspace thing, not a kernel thing, please solve it in
> userspace.
>
To solve it in userspace, we need mapping of a device name to a device
every boot-up time. But if kernel messages can show preferred name, we
can identify a device from only kernel messages.
Thanks,
--
Nao NISHIJIMA
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., YOKOHAMA Research Laboratory
Email: nao.nishijima.xt@hitachi.com
prev parent reply other threads:[~2011-06-17 5:58 UTC|newest]
Thread overview: 51+ 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 12:28 ` Nao Nishijima
2011-06-17 11:36 ` Nao Nishijima
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 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-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 [this message]
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=4DFAECF2.9060105@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 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).