Message-ID: <20110827132044.GN2632@htj.dyndns.org>
Date:	Sat, 27 Aug 2011 15:20:44 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Nao Nishijima <nao.nishijima.xt@...achi.com>
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, kay.sievers@...il.com
Subject: Re: [-v3 PATCH 0/3] Persistent device name using alias

Hello, Nao.

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.

Thanks.

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