linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nao Nishijima <nao.nishijima.xt@hitachi.com>
To: gregkh@suse.de, James.Bottomley@suse.de, rwheeler@redhat.com
Cc: linux-kernel@vger.kernel.org,
	linux-hotplug-devel@lists.sourceforge.net,
	linux-hotplug@vger.kernel.org, masami.hiramatsu.pt@hitachi.com
Subject: [RFD] Device Renaming Mechanism
Date: Fri, 08 Oct 2010 05:23:32 +0000	[thread overview]
Message-ID: <4CAEAAD4.2080504@hitachi.com> (raw)

Hi,

I'm trying to solve a device name(or device node) mismatch problem caused by
device configuration changes. Now I have an idea of device renaming to solve it,
and would like to request for comments from kernel developers.


Device Name Mismatch
==========

Device names(e.g. sda) are assigned by the order of driver loading and device
recognizing (usually from small bus number). This may cause a device name
mismatch between previous and current boot whenever the device configuration is
changed. Suppose there is an application opens disk via /dev/sdb. When device
configuration changing (hot-plug, device breakdown) or system configuration
changing(driver loading order, changing modprobe.conf) causes changing order
device names. This device names does not always point to same disks.

This mismatch causes unexpected disk access and redundancy miss setting (e.g.
Multipath, software-raid), if you use device file names to a configuration file.


Udev Solution
======
Typically we use to avoid this problem we uses persistent device names provided
by udev.

Udev makes persistent symbolic links(by-{id, uuid, path, label}) pointing to each
device based on device information. Applications access the device via these
symbolic links. Udev solves mismatch between device name and physical disk.
However the persistent name mismatches kernel's device name.
This mismatch causes following 4 issues.

Issue 1: /proc/partitions, /proc/diskstat gives you device names
We have to run "ls -l /dev/disk/by-*" or "udevadm" for finding corresponding
persistent symbolic links.

Issue 2: dmesg output device name instead of persistent symbolic links
Users might not know which disk is sdX, because they identify the disk by a
persistent symbolic link.

Issue 3: Some system commands don't accept symbolic link(e.g. df, iostat,...)
These commands just expect sdX device name or check input by /proc information.
This will also occur on several GNOME/KDE/etc GUI sysadmin tools. :(

Issue 4: Undecided symbolic link
Even if we would like to introduce device names/persistent symbolic links
mapping tool to solve it, we can not determine a symbolic link from a device,
because several symbolic links point a device file.

Therefore, I think the symbolic link is not enough to solve. We need a
better solution.


Proposal
====
I'd like to propose introducing device renaming interface to solve these issues.

I think renaming device name in the kernel is the simplest way to solve mismatch
dmesg and /proc information. This can be done while kernel booting up(like
ifcfg). Of course, udev still needs to assign new name for each device via that
interface.

This proposal just requests to add a simple interface to kernel as below. And we
can continue to use user program without any modification.

int rename_device(const char *newname, const char *oldname)

Any comments, or suggestions are very welcome!
Best Regards,

-- 
Nao NISHIJIMA
2nd Dept. Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
Email: nao.nishijima.xt@hitachi.com

             reply	other threads:[~2010-10-08  5:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-08  5:23 Nao Nishijima [this message]
2010-10-08 20:48 ` [RFD] Device Renaming Mechanism Greg KH
2010-10-18 11:43   ` Nao Nishijima
2010-10-18 12:33     ` Kay Sievers
2010-10-25 10:55       ` Nao Nishijima
2010-11-02  7:00 ` Jon Masters
2010-11-02 11:14   ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CAEAAD4.2080504@hitachi.com \
    --to=nao.nishijima.xt@hitachi.com \
    --cc=James.Bottomley@suse.de \
    --cc=gregkh@suse.de \
    --cc=linux-hotplug-devel@lists.sourceforge.net \
    --cc=linux-hotplug@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=rwheeler@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).