[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E58C3BD.3000609@hitachi.com>
Date: Sat, 27 Aug 2011 19:15:25 +0900
From: Nao Nishijima <nao.nishijima.xt@...achi.com>
To: Tejun Heo <tj@...nel.org>
Cc: 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
Subject: Re: [-v3 PATCH 0/3] Persistent device name using alias
Hi Tejun,
Thank you for your comments.
(2011/08/25 19:16), Tejun Heo wrote:
> Hello,
>
> On Thu, Aug 25, 2011 at 06:03:59PM +0900, Nao Nishijima wrote:
>> This patch series provide an "alias" of the disk into kernel messages.
>>
>> A raw device name of a disk does not always point a same disk at each boot-up
>> time. Therefore, users have to use persistent device names, which udev creates
>> to always access the same disk. However, kernel messages still display the raw
>> device names.
>>
>> My proposal is that users can use and see persistent device names which were
>> assigned by themselves because users expect same name to point same disk
>> anytime.
>>
>> Why need to modify kernel messages?
>> - We can see mapping of device names and persistent device names in udev log.
>> If those logs output to syslog, we can search persistent device name from
>> device name, but it can cause a large amount of syslog output.
>>
>> - If we can use the persistent device names and can always see the same name on
>> the kernel log, we don't need to pay additional cost for searching and picking
>> a correct pair of device name and persistent device name from udev log.
>>
>> - Kernel messages are output to serial console when kenel crashes, it's so hard
>> to convert a device name to the alias.
>
> Just some general comments. This may already be a horse which is
> beaten to death but anyways...
>
> I'm not really convinced this is something we need. What we're
> missing is structured error reporting which can be understood,
> processed, presented and reacted by programs implementing system
> management policies. Such facility would be useful in general but for
> block devices I think it's a must that we're sorely missing.
Yes. I agree that we need structured error reporting.
This facility will be discussed by Kay Sievers at Kernel Summit.
However I think that even if it is applied in kernel, "alias" is still
necessary because users want to use and see friendly name which can be
simple, short and preference, instead of persistent device names (e.g.
/dev/disk/by-uuid/35d4def7-9098-448c-8cc3-b0cb74c8670b).
> Free format kernel message is a very undiscoverable way of
> communicating these information. For developing and debugging, it's
> fine. It's easy, flexible and you don't really have to think too much
> about what should be presented how. For anything else, it's basically
> horrible.
>
> I don't really see what the point of this feature is. For developing
> and debugging, pretty names might be nice but almost completely
> unnecessary. For anything else, this falls way too short and can be
> easily replaced by some smart scripting from userland. After all,
> matching different device names is the least of the worries when
> trying to use kernel log for general management and post-processing w/
> good amount of heuristics is necessary to be useful anyway.
Our concern is the failure analysis. For example, when the disk failure
happened, we need to identify the disk from kernel log.
Kernel messages are output to serial console when kernel crashes.
It's so hard to convert a device name to the alias. Thus the script
can't always convert the name.
Also, the alias is useful for users because they can use and see the
same name everywhere(e.g. commands, kernel log).
Best regards,
--
Nao NISHIJIMA
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., YOKOHAMA Research Laboratory
Email: nao.nishijima.xt@...achi.com
--
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