linux-kernel.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-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

      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).