* Re: 2.6.15: mdrun, udev -- who creates nodes?
@ 2006-01-31 19:26 ` linas
0 siblings, 0 replies; 24+ messages in thread
From: linas @ 2006-01-31 19:26 UTC (permalink / raw)
To: Jason Lunz, neilb; +Cc: linux-hotplug-devel, linux-raid
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.=20
> > 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.6.15: mdrun, udev -- who creates nodes?
2006-01-31 19:26 ` linas
@ 2006-01-31 20:19 ` Molle Bestefich
-1 siblings, 0 replies; 24+ messages in thread
From: Molle Bestefich @ 2006-01-31 20:19 UTC (permalink / raw)
To: linas; +Cc: Jason Lunz, neilb, linux-hotplug-devel, linux-raid
linas@austin.ibm.com wrote:
> > 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?
I *think* that "the raid developers" may be, for once, choosing words
not-so-wisely when talking about "deprecating autoassembly".
Last time I heard that I choked as well, only to find out later that
Neil's notion of what auto-assembly is differed substantially from my
own.
Isn't there a faq/wiki somewhere where the official opinion on
"autoassembly deprecation" and exactly what that means can go?
-------------------------------------------------------
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_______________________________________________
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.6.15: mdrun, udev -- who creates nodes?
@ 2006-01-31 20:19 ` Molle Bestefich
0 siblings, 0 replies; 24+ messages in thread
From: Molle Bestefich @ 2006-01-31 20:19 UTC (permalink / raw)
To: linas; +Cc: Jason Lunz, neilb, linux-hotplug-devel, linux-raid
linas@austin.ibm.com wrote:
> > 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?
I *think* that "the raid developers" may be, for once, choosing words
not-so-wisely when talking about "deprecating autoassembly".
Last time I heard that I choked as well, only to find out later that
Neil's notion of what auto-assembly is differed substantially from my
own.
Isn't there a faq/wiki somewhere where the official opinion on
"autoassembly deprecation" and exactly what that means can go?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.6.15: mdrun, udev -- who creates nodes?
2006-01-31 20:19 ` Molle Bestefich
@ 2006-01-31 20:52 ` Jason Lunz
-1 siblings, 0 replies; 24+ messages in thread
From: Jason Lunz @ 2006-01-31 20:52 UTC (permalink / raw)
To: Molle Bestefich; +Cc: linas, neilb, linux-hotplug-devel, linux-raid
On Tue, Jan 31, 2006 at 09:19:16PM +0100, Molle Bestefich wrote:
> I *think* that "the raid developers" may be, for once, choosing words
> not-so-wisely when talking about "deprecating autoassembly".
You're right, I should be careful not to imply anything Neil didn't
actually say. What he said was:
> From: Neil Brown <neilb <at> suse.de>
...
> And if other partition styles wanted to add support for raid auto
> detect, tell them "no". It is perfectly possible and even preferable
> to live without autodetect. We should support legacy usage (those
> above) but should discourage any new usage.
which is a far cry from officially deprecating anything. My point was
that the outlined solution for having udev create /dev/md* nodes could
not work on all platforms because it required raid autodetect, and it
looks unlikely that raid autodetect will be universally supported.
Jason
-------------------------------------------------------
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.6.15: mdrun, udev -- who creates nodes?
@ 2006-01-31 20:52 ` Jason Lunz
0 siblings, 0 replies; 24+ messages in thread
From: Jason Lunz @ 2006-01-31 20:52 UTC (permalink / raw)
To: Molle Bestefich; +Cc: linas, neilb, linux-hotplug-devel, linux-raid
On Tue, Jan 31, 2006 at 09:19:16PM +0100, Molle Bestefich wrote:
> I *think* that "the raid developers" may be, for once, choosing words
> not-so-wisely when talking about "deprecating autoassembly".
You're right, I should be careful not to imply anything Neil didn't
actually say. What he said was:
> From: Neil Brown <neilb <at> suse.de>
...
> And if other partition styles wanted to add support for raid auto
> detect, tell them "no". It is perfectly possible and even preferable
> to live without autodetect. We should support legacy usage (those
> above) but should discourage any new usage.
which is a far cry from officially deprecating anything. My point was
that the outlined solution for having udev create /dev/md* nodes could
not work on all platforms because it required raid autodetect, and it
looks unlikely that raid autodetect will be universally supported.
Jason
-------------------------------------------------------
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=103432&bid=230486&dat=121642
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.6.15: mdrun, udev -- who creates nodes?
2006-01-31 20:52 ` Jason Lunz
@ 2006-01-31 21:13 ` linas
-1 siblings, 0 replies; 24+ messages in thread
From: linas @ 2006-01-31 21:13 UTC (permalink / raw)
To: Jason Lunz; +Cc: Molle Bestefich, neilb, linux-hotplug-devel, linux-raid
I was reacting to the following:
> > From: Neil Brown <neilb <at> suse.de>
> > It is perfectly possible and even preferable
> > to live without autodetect.
I didn't see how it could be "preferable", and illustrated this
with the sysadmin story.
--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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.6.15: mdrun, udev -- who creates nodes?
@ 2006-01-31 21:13 ` linas
0 siblings, 0 replies; 24+ messages in thread
From: linas @ 2006-01-31 21:13 UTC (permalink / raw)
To: Jason Lunz; +Cc: Molle Bestefich, neilb, linux-hotplug-devel, linux-raid
I was reacting to the following:
> > From: Neil Brown <neilb <at> suse.de>
> > It is perfectly possible and even preferable
> > to live without autodetect.
I didn't see how it could be "preferable", and illustrated this
with the sysadmin story.
--linas
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.6.15: mdrun, udev -- who creates nodes?
2006-01-31 21:13 ` linas
@ 2006-01-31 21:58 ` Molle Bestefich
-1 siblings, 0 replies; 24+ messages in thread
From: Molle Bestefich @ 2006-01-31 21:58 UTC (permalink / raw)
To: linas; +Cc: Jason Lunz, neilb, linux-hotplug-devel, linux-raid
linas wrote:
> I was reacting to the following:
> > > From: Neil Brown <neilb <at> suse.de>
> > > It is perfectly possible and even preferable
> > > to live without autodetect.
>
> I didn't see how it could be "preferable", and illustrated this
> with the sysadmin story.
Certainly it isn't, and now I remember the point.
Quoting Luca Berra:
> the in kernel auto assembly should be removed for good
> it should be replaced by auto assembly in user space (mdadm),
> which does not suffer from the problems that in-kernel has.
If people could start saying
"we need to get rid of in-kernel autodetection"
instead of
"we need to get rid of autodetection",
I think there would be much less confusion.
-------------------------------------------------------
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_______________________________________________
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.6.15: mdrun, udev -- who creates nodes?
@ 2006-01-31 21:58 ` Molle Bestefich
0 siblings, 0 replies; 24+ messages in thread
From: Molle Bestefich @ 2006-01-31 21:58 UTC (permalink / raw)
To: linas; +Cc: Jason Lunz, neilb, linux-hotplug-devel, linux-raid
linas wrote:
> I was reacting to the following:
> > > From: Neil Brown <neilb <at> suse.de>
> > > It is perfectly possible and even preferable
> > > to live without autodetect.
>
> I didn't see how it could be "preferable", and illustrated this
> with the sysadmin story.
Certainly it isn't, and now I remember the point.
Quoting Luca Berra:
> the in kernel auto assembly should be removed for good
> it should be replaced by auto assembly in user space (mdadm),
> which does not suffer from the problems that in-kernel has.
If people could start saying
"we need to get rid of in-kernel autodetection"
instead of
"we need to get rid of autodetection",
I think there would be much less confusion.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.6.15: mdrun, udev -- who creates nodes?
2006-01-31 21:58 ` Molle Bestefich
(?)
@ 2006-02-01 9:27 ` Andy Smith
2006-02-01 19:44 ` Luca Berra
2006-02-02 1:27 ` Neil Brown
-1 siblings, 2 replies; 24+ messages in thread
From: Andy Smith @ 2006-02-01 9:27 UTC (permalink / raw)
To: linux-raid
[-- Attachment #1: Type: text/plain, Size: 637 bytes --]
On Tue, Jan 31, 2006 at 10:58:03PM +0100, Molle Bestefich wrote:
> Quoting Luca Berra:
> > the in kernel auto assembly should be removed for good
> > it should be replaced by auto assembly in user space (mdadm),
> > which does not suffer from the problems that in-kernel has.
>
> If people could start saying
> "we need to get rid of in-kernel autodetection"
> instead of
> "we need to get rid of autodetection",
> I think there would be much less confusion.
And force us all to use initrd/initramfs :(
--
http://strugglers.net/wiki/Xen_hosting -- A Xen VPS hosting hobby
Encrypted mail welcome - keyid 0x604DE5DB
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.6.15: mdrun, udev -- who creates nodes?
2006-02-01 9:27 ` Andy Smith
@ 2006-02-01 19:44 ` Luca Berra
2006-02-01 22:14 ` Andy Smith
2006-02-02 1:27 ` Neil Brown
1 sibling, 1 reply; 24+ messages in thread
From: Luca Berra @ 2006-02-01 19:44 UTC (permalink / raw)
To: linux-raid
On Wed, Feb 01, 2006 at 09:27:58AM +0000, Andy Smith wrote:
>On Tue, Jan 31, 2006 at 10:58:03PM +0100, Molle Bestefich wrote:
>> Quoting Luca Berra:
>> > the in kernel auto assembly should be removed for good
>> > it should be replaced by auto assembly in user space (mdadm),
>> > which does not suffer from the problems that in-kernel has.
>>
>> If people could start saying
>> "we need to get rid of in-kernel autodetection"
>> instead of
>> "we need to get rid of autodetection",
>> I think there would be much less confusion.
>
>And force us all to use initrd/initramfs :(
>
i believe that if you looked in this ml archives you'll know you can use
the kernel command line to build an array, if you don't want to use
initrd/initramfs.
L.
--
Luca Berra -- bluca@comedia.it
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: 2.6.15: mdrun, udev -- who creates nodes?
2006-02-01 19:44 ` Luca Berra
@ 2006-02-01 22:14 ` Andy Smith
0 siblings, 0 replies; 24+ messages in thread
From: Andy Smith @ 2006-02-01 22:14 UTC (permalink / raw)
To: linux-raid
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
On Wed, Feb 01, 2006 at 08:44:19PM +0100, Luca Berra wrote:
> On Wed, Feb 01, 2006 at 09:27:58AM +0000, Andy Smith wrote:
> >On Tue, Jan 31, 2006 at 10:58:03PM +0100, Molle Bestefich wrote:
> >>If people could start saying
> >> "we need to get rid of in-kernel autodetection"
> >>instead of
> >> "we need to get rid of autodetection",
> >>I think there would be much less confusion.
> >
> >And force us all to use initrd/initramfs :(
> >
> i believe that if you looked in this ml archives you'll know you can use
> the kernel command line to build an array, if you don't want to use
> initrd/initramfs.
I am aware and I do. However that is in-kernel. If it needs
userland as has been stated here then it requires initrd, no?
--
http://strugglers.net/wiki/Xen_hosting -- A Xen VPS hosting hobby
Encrypted mail welcome - keyid 0x604DE5DB
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.6.15: mdrun, udev -- who creates nodes?
2006-02-01 9:27 ` Andy Smith
2006-02-01 19:44 ` Luca Berra
@ 2006-02-02 1:27 ` Neil Brown
1 sibling, 0 replies; 24+ messages in thread
From: Neil Brown @ 2006-02-02 1:27 UTC (permalink / raw)
To: Andy Smith; +Cc: linux-raid
On Wednesday February 1, andy@lug.org.uk wrote:
> On Tue, Jan 31, 2006 at 10:58:03PM +0100, Molle Bestefich wrote:
> > Quoting Luca Berra:
> > > the in kernel auto assembly should be removed for good
> > > it should be replaced by auto assembly in user space (mdadm),
> > > which does not suffer from the problems that in-kernel has.
> >
> > If people could start saying
> > "we need to get rid of in-kernel autodetection"
> > instead of
> > "we need to get rid of autodetection",
> > I think there would be much less confusion.
>
> And force us all to use initrd/initramfs :(
Don't think of it as 'forcing' you. Think of it as encouraging you to
be an early adopter...
I suspect it won't be many years (maybe 1) before you have to have an
initramfs to boot. There will be a standard one distributed with the
kernel, but it will (hopefully) be fairly easy to add stuff.
So get with the program. Initramfs is *easy*. Just DO it.
(mdadm-2.2 comes with a script to make an initramfs which "works for me").
NeilBrown
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.6.15: mdrun, udev -- who creates nodes?
2006-01-31 19:26 ` linas
@ 2006-01-31 21:44 ` Luca Berra
-1 siblings, 0 replies; 24+ messages in thread
From: Luca Berra @ 2006-01-31 21:44 UTC (permalink / raw)
To: linas; +Cc: Jason Lunz, neilb, linux-hotplug-devel, linux-raid
On Tue, Jan 31, 2006 at 01:26:43PM -0600, linas wrote:
>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?
please, no, not again:
this particular horse has been beaten to death many times before.
the in kernel auto assembly should be removed for good (read the
linux-raid list archive to understand why)
it should be replaced by auto assembly in user space (mdadm), which does
not suffer from the problems that in-kernel has. neither it does suffer
from a poor configuration file like the (unmaintained) raidtools had.
and is much more cleaner and maintainable.
L.
--
Luca Berra -- bluca@comedia.it
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
-------------------------------------------------------
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
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: 2.6.15: mdrun, udev -- who creates nodes?
@ 2006-01-31 21:44 ` Luca Berra
0 siblings, 0 replies; 24+ messages in thread
From: Luca Berra @ 2006-01-31 21:44 UTC (permalink / raw)
To: linas; +Cc: Jason Lunz, neilb, linux-hotplug-devel, linux-raid
On Tue, Jan 31, 2006 at 01:26:43PM -0600, linas wrote:
>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.=20
>> > 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?
please, no, not again:
this particular horse has been beaten to death many times before.
the in kernel auto assembly should be removed for good (read the
linux-raid list archive to understand why)
it should be replaced by auto assembly in user space (mdadm), which does
not suffer from the problems that in-kernel has. neither it does suffer
from a poor configuration file like the (unmaintained) raidtools had.
and is much more cleaner and maintainable.
L.
--
Luca Berra -- bluca@comedia.it
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.6.15: mdrun, udev -- who creates nodes?
2006-01-31 19:26 ` linas
@ 2006-02-10 22:46 ` Bill Davidsen
-1 siblings, 0 replies; 24+ messages in thread
From: Bill Davidsen @ 2006-02-10 22:46 UTC (permalink / raw)
To: linas; +Cc: Jason Lunz, neilb, linux-hotplug-devel, linux-raid
linas wrote:
>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.
>
I fear you don't understand how the auto detect and assemble works. Or
more to the point what it does, since how it works is somewhat more
complex. If you use partitions and UUID, you can just plug in the drives
any old place and they will be found and recognised in spite of that. As
long as you have a boot drive where the BIOS will use it, mdadm with
find your stuff and put it together correctly. Neil does more magic than
harry Potter!
I know someone who gave this a real life test, although I'd not say who.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
-------------------------------------------------------
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.6.15: mdrun, udev -- who creates nodes?
@ 2006-02-10 22:46 ` Bill Davidsen
0 siblings, 0 replies; 24+ messages in thread
From: Bill Davidsen @ 2006-02-10 22:46 UTC (permalink / raw)
To: linas; +Cc: Jason Lunz, neilb, linux-hotplug-devel, linux-raid
linas wrote:
>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.=20
>>>>
>>>>
>>>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.
>
I fear you don't understand how the auto detect and assemble works. Or
more to the point what it does, since how it works is somewhat more
complex. If you use partitions and UUID, you can just plug in the drives
any old place and they will be found and recognised in spite of that. As
long as you have a boot drive where the BIOS will use it, mdadm with
find your stuff and put it together correctly. Neil does more magic than
harry Potter!
I know someone who gave this a real life test, although I'd not say who.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
^ permalink raw reply [flat|nested] 24+ messages in thread