[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CC56206.8080700@hitachi.com>
Date: Mon, 25 Oct 2010 19:55:02 +0900
From: Nao Nishijima <nao.nishijima.xt@...achi.com>
To: Kay Sievers <kay.sievers@...y.org>, greg@...ah.com
Cc: James.Bottomley@...e.de, rwheeler@...hat.com,
linux-kernel@...r.kernel.org, linux-hotplug@...r.kernel.org,
masami.hiramatsu.pt@...achi.com, Matt_Domsch@...l.com
Subject: Re: [RFD] Device Renaming Mechanism
Hello,
(2010/10/18 21:33), Kay Sievers wrote:
>
> In short: it's a complete nightmare from the view of reliability, and
> I strongly suggest not even to think about to try that model on any
> other subsystem.
I see. I understood that network interface and block device are different.
> Device-mapper could maybe make the dm UUID mandatory, and use it as
> the device name. It will break a bunch of tools, which match on device
> names, but I guess it *could* be made working (if it does not involve
> any later renaming).
Indeed, device-mapper can provide a fixed name. However, still there is
mismatch between the dm device name and the troubling device name in kernel
log. That is the reason why I'm still sticking around the device renaming method.
In addition, using of device-mapper is worry about the performance and
management cost.
I think the method of using the intermediate device is the simplest solution.
Furthermore that method is compatible with old applications which are hard to
modify.
> I wouldn't even try. Besides the mentioned device mapper
> mandatory/non-changeable UUID==device-name approach which could work,
> I don't think that renaming of sd devices can be made working, without
> rewriting half of all existing userspace. :)
Even though, if it is only way to solve log-mismatch problem, I'd rather try to
rewrite a half of those tools. :-)
>
> Kay
>
>
Thank you for your advice.
Best Regards,
--
Nao NISHIJIMA
2nd Dept. Linux Technology Center
Hitachi, Ltd., Systems Development 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