Date:	Sun, 28 Aug 2011 20:07:09 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	Nao Nishijima <nao.nishijima.xt@...achi.com>,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	Jens Axboe <axboe@...nel.dk>,
	James.Bottomley@...senpartnership.com,
	dle-develop@...ts.sourceforge.net,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	yrl.pp-manager.tt@...achi.com, kay.sievers@...il.com
Subject: Re: [-v3 PATCH 0/3] Persistent device name using alias

On Sat, Aug 27, 2011 at 15:20, Tejun Heo <tj@...nel.org> wrote:
> On Sat, Aug 27, 2011 at 09:54:29PM +0900, Nao Nishijima wrote:
>> > Hmm... I don't follow.  Why wouldn't it be able to?  All the
>> > informations are in the log.  It is messy but it's there.  If you want
>>
>> In many cases, the script is able to convert the name. However there is
>> the special case that the logs do not exist in memory and disk due to
>> the crash except console.
>
> Sorry but I still don't get it.  If you can extract the log, the
> information is there and w/ remote logging (be it via serial or
> network), the information always has to be there.  Are you talking
> about the case where somehow only the video console somehow succeeds
> to print out oops?  I don't think that's a common case as serial (also
> on IPMI) tends to be pretty robust, often more robust than vide
> output, and even when such case occurs, the only thing you want is
> mapping kernel device name to more recognizable information, which
> isn't difficult at all.  If you wanna do it in a really simple manner,
> just save udisks --dump output after boot and each hotplug event and
> write a simple script to search it.
>
>> > more structured information, u{dev|disks} already maintain device
>> > libarary - what maps to what, connected how with what attributes and
>> > so on.  Sending them off to the log machine as device hotplug events
>> > occur and consulting it when post-processing log message would work
>> > fine.  All you need is just some python scripting.  I don't really see
>> > much point in messing with device names directly.  The only thing is
>> > that the raw log would be prettier.  I don't think that is useful
>> > enough to justify changing kernel device names.
>>
>> A kernel device names (e.g. sda) is not useful information because it
>> doesn't always point the same disk at each boot-up time.
>
> Eh?  What difference does that make?  Just make the target machines
> send up-to-date disk config info to the log server.
>
>> An alias is just an option and provides the ability to give all
>> kernel devices a "preferred name".
>>
>> By default, dev_printk's will show a kernel device name. They show an
>> alias only when the user assigns a "preferred name" to an alias.
>> Even if the persistend device name is used, the device names in logs are
>> different from the name that the users are using. So, an alias helps the
>> user identify the disk.
>
> Yes, I do understand what it's doing and can see there can be cases it
> can be somewhat useful but I still think it's too adhoc an approach
> which doesn't really justify itself.  It just does too little to solve
> the actual problem and even that 'little' part isn't very trivial - it
> adds whole lot of policy decisions to make and I'm pretty sure it will
> cause good amount of havoc w/ all the system tools which currently
> don't expect block device names to change to some admin determined
> free format string on the fly.

My take on this in short again:
The very same thing that needs to store the 'pretty name' in the
kernel here, can instead just log that name along with the kernel name
to /dev/kmsg. It ends up in the kernel log buffer and is the marker to
safely match all later log entries.

This can be done today, even on many years old distros, with a single
udev rule and a tiny program. It needs no kernel or tool changes and
gives almost all the benefits of the 'pretty name' infrastructure.

Kay
--
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