Message-ID: <4DFA3E1A.9050207@interlog.com>
Date:	Thu, 16 Jun 2011 13:32:10 -0400
From:	Douglas Gilbert <dgilbert@...erlog.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	Greg KH <greg@...ah.com>,
	Nao Nishijima <nao.nishijima.xt@...achi.com>,
	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
	kay.sievers@...y.org, jcm@...hat.com, hare@...e.de,
	stefanr@...6.in-berlin.de, yrl.pp-manager.tt@...achi.com
Subject: Re: [PATCH 1/3] [RFC] genhd: add a new attribute in device structure

On 11-06-16 11:50 AM, James Bottomley wrote:
> On Thu, 2011-06-16 at 08:41 -0700, Greg KH wrote:
>> On Thu, Jun 16, 2011 at 09:03:43PM +0900, Nao Nishijima wrote:
>>> Hi Greg,
>>>
>>> (2011/06/16 0:33), Greg KH wrote:
>>>> On Wed, Jun 15, 2011 at 05:16:28PM +0900, Nao Nishijima wrote:
>>>>> Allow users to set the preferred name of device via sysfs interface.
>>>>>
>>>>> (Exsample) sda ->  foo
>>>>> # echo foo>  /sys/block/sda/preferred_name
>>>>>
>>>>> Suggested-by: James Bottomley<James.Bottomley@...senPartnership.com>
>>>>> Suggested-by: Jon Masters<jcm@...hat.com>
>>>>> Signed-off-by: Nao Nishijima<nao.nishijima.xt@...achi.com>
>>>>
>>>> You don't document this new sysfs file (which is required), nor do you
>>>> explain what it is for and how to use it.
>>>>
>>>> Please do that in this patch, and in a Documentation/ABI/ file for any
>>>> new sysfs file you create.
>>>>
>>>
>>> I'm afraid that my explanation was not enough.
>>> I will add explanation to this patch and Documentation/ABI file.
>>>
>>>> I still fail to understand how a "preferred" file will help anyone out
>>>> here at all...
>>>>
>>>
>>> Let me explain, users cannot identify a device from a device name
>>> because device names may change at each boot up time. If kernel show
>>> preferred names in kernel messages, users can easily identify a device
>>> from kernel messages.
>>
>> I understand your request for the kernel to print out these types of
>> names, but I'm still not sold on this being an issue that is the
>> kernel's to deal with at all.
>>
>> Again, how would you handle multiple persistant names for the same
>> device being used at the same time?
>>
>> And again, why not just fix the userspace tools?  That is trivial to do
>> so and again, could have been done by now in the years this has been
>> discussed.
>
> So I can summarise where I think we are in these discussions:
>
> We provide the ability to give all kernel devices a "preferred name".
> By default this will be the device name the kernel would have originally
> assigned.  the dev_printk's will use the preferred name, and it will be
> modifiable from user space.  All the kernel will do is print out
> whatever it is ... no guarantees of uniqueness or specific format will
> be made.  Since we're only providing one preferred_name file, the kernel
> can only have one preferred name for a device at any given time
> (although it is modifiable on the fly as many times as the user
> chooses).
>
> The design is to use this preferred name to implement what Hitachi wants
> in terms of persistent name, but we don't really care.
>
> 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.
>
> This will ensure that kernel output and udev input are consistent.  It
> will still require that user space utilities which derive a name for a
> device will need modifying to print out the preferred name.

I like the idea but wonder about some of the details.

Basically the problem is that you find yourself at the
keyboard of a server with a non-trivial storage set up
where something is wrong. The device names that a tool
like lsscsi shows (by default) are device nodes in
the /dev directory. For whatever reason those names may
not match what dmesg and kernel logs are showing.

Whether Greg likes it or not, pretty well all user space
tools and those who use them, look around the /dev directory
for devices **.

lsscsi by default shows the first name in the /dev directory
that matches the major and minor in
/sys/block/<kernel_name>/dev ***. With the '--kname' option
lsscsi will show the kernel (/sys/block) device name instead.


As James' notes each storage device can only have one
"preferred name" at a time. But how can that preferred name
be represented in sysfs ? If /sys/block/<kernel_name>
suddenly changed to /sys/block/<preferred_name> that would
be very disruptive. I would prefer something like
/sys/class/block_preferred_name/<preferred_name> was introduced
as a symlink to /sys/block/<kernel_name> but that would require
that all <preferred_name>s were unique. [Not a bad restriction
IMO]. If the <preferred_name> was only placed in the
/sys/block/<kernel_name> directory that would be ugly from
the user space tool point of view.


**  I write several storage user space tools and can only
     think of one instance where a sysfs "device" node is
     accepted (smp_utils with the sgv4(bsg) interface) and
     that is in addition to a /dev/bsg device node.

*** lsscsi could be smarter and drill down through /dev 's
     sub-directories until a match is found. It could also
     flag that the /dev name and the kernel_name are
     different.

Doug Gilbert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists