From: linas@austin.ibm.com (linas)
To: Jason Lunz <lunz@falooley.org>, neilb@suse.de
Cc: linux-hotplug-devel@lists.sourceforge.net, linux-raid@vger.kernel.org
Subject: Re: 2.6.15: mdrun, udev -- who creates nodes?
Date: Tue, 31 Jan 2006 19:26:43 +0000 [thread overview]
Message-ID: <20060131192643.GU19465@austin.ibm.com> (raw)
In-Reply-To: <dro3ue$ntb$1@sea.gmane.org>
On Tue, Jan 31, 2006 at 04:40:46PM +0000, Jason Lunz was heard to remark:
> md@Linux.IT said:
> >> -- kernel scans /dev/hda1, looking for md superblock
> >> -- kernel assembles devices according to info found in the superblocks
> >> -- udev creates /dev/md0, etc.
> > The problem is that some users and distributions build the drivers as
> > modules and/or disable in-kernel auto-assembly.
>
> Not only that, the raid developers themselves consider autoassembly
> deprecated.
>
> http://article.gmane.org/gmane.linux.kernel/373620
Hmm. My knee-jerk, didn't-stop-to-think-about-it reaction is that
this is one of the finest features of linux raid, so why remove it?
Speaking as a real-life sysadmin, with actual servers and actual failed
disks, disk cables and disk controllers, this is a life-saving feature.
Persistant naming of devices in Linux has long been a problem, and in
this case, it seemed to work.
<story>
I once had an ide controller fail on an x86 board. I bought a new
controller at the local store, recabled the disks, and booted.
I was alarmed to find that the system was trying to mount /home
as /usr, and /usr as /lib, etc. Turned out that /dev/hdc had
gotten renamed as /dev/hde, etc. and had to go through a long,
painful, rocket-science (yes, I *do* have a PhD) boot-floppy rescue
to restore the system to working order.
I shudder to think what would have happened if RAID reconstruction
had started based on faulty device names. Worse, as part of my rescue
ops, I had to make multle copies of /etc/fstab, which resided on
different disks (my root volume was raided), as well as the boot
floppy, and each contained inconsistent info (needed to bootstrap
my way back). Along the way, I made multiple errors in editing
the /etc/fstab since I could not keep them straight; twiddling
BIOS settings added to the confusion. If this had been /etc/raid.conf
instead, with reconstruction triggered off of it, this could have
been an absolute disaster.
</story>
Based on the above, real-life experience, my gut reaction is
raid assembly based on config files is a bad idea. I don't
understand how innocent, "minor" errors made by the sysadmin
won't result in catastrophic data loss.
--linas
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2006-01-31 19:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-29 11:40 2.6.15: mdrun, udev -- who creates nodes? Moshe Yudkowsky
2006-01-29 12:35 ` Marco d'Itri
2006-01-29 14:49 ` Moshe Yudkowsky
2006-01-30 20:42 ` linas
2006-01-30 20:47 ` Marco d'Itri
2006-01-31 16:40 ` Jason Lunz
2006-01-31 19:26 ` linas [this message]
2006-01-31 20:19 ` Molle Bestefich
2006-01-31 20:52 ` Jason Lunz
2006-01-31 21:13 ` linas
2006-01-31 21:58 ` Molle Bestefich
2006-01-31 21:44 ` Luca Berra
2006-02-10 22:46 ` Bill Davidsen
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=20060131192643.GU19465@austin.ibm.com \
--to=linas@austin.ibm.com \
--cc=linux-hotplug-devel@lists.sourceforge.net \
--cc=linux-raid@vger.kernel.org \
--cc=lunz@falooley.org \
--cc=neilb@suse.de \
/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).