Re: [-v3 PATCH 0/3] Persistent device name using alias

From: Bernd Schubert
Date: Tue Aug 30 2011 - 17:53:52 EST

On 08/28/2011 08:07 PM, Kay Sievers wrote:
On Sat, Aug 27, 2011 at 15:20, Tejun Heo<tj@xxxxxxxxxx> 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.

Could you please explain exactly how? Simply replace sd{X} by the preferred name in /dev/kmsg? How do make make sure you do not replace something that is not supposed to be replaced? I think unless you plan to modify existing kernel device message you cannot, as sd{X} is too general.
And how does /dev/kmsg solve the serial console problem?

However, I think a real technical issue with any udev device name rules remains - it often does not work well with multipath devices. Alua partly solves that problem, but only if there is a direct connection to each of the alua controllers. But if there is a switch in between, there are often several devices with the same alua score. And the situation is even worse with multipath hardware that does not know alua at all.
So for many multipath devices it probably would not make sense to set alias names. But especially on those system you often would like to have suitable alias names, as it gets a bit chaotic without (I had to deal with 30 or even 60 devices x 8 paths in the past...).

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