Hello,
(2011/08/27 19:26), Tejun Heo wrote:
> (cc'ing Kay)
> Hello,
>
> On Sat, Aug 27, 2011 at 07:15:25PM +0900, Nao Nishijima wrote:
>> 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.
>
> 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.
> 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.
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.
Best regards,
--
Nao NISHIJIMA
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., YOKOHAMA Research Laboratory
Email： nao.nishijima.xt@xxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
