From: Bill Davidsen <davidsen@tmr.com>
To: Alexandre Oliva <aoliva@redhat.com>
Cc: Neil Brown <neilb@suse.de>, Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org
Subject: Re: let md auto-detect 128+ raid members, fix potential race condition
Date: Wed, 02 Aug 2006 12:47:20 -0400 [thread overview]
Message-ID: <44D0D718.5050505@tmr.com> (raw)
In-Reply-To: <orlkq8f8ge.fsf@free.oliva.athome.lsd.ic.unicamp.br>
Alexandre Oliva wrote:
> On Aug 1, 2006, Bill Davidsen <davidsen@tmr.com> wrote:
>
>> I rarely think you are totally wrong about anything RAID, but I do
>> believe you have missed the point of autodetect. It is intended to
>> work as it does now, building the array without depending on some user
>> level functionality.
>
> Well, it clearly depends on at least some user level functionality
> (the ioctl that triggers autodetect). Going from that to a
> full-fledged mdadm doesn't sound like such a big deal to me.
>
>> I don't personally see the value of autodetect for putting together
>> the huge number of drives people configure. I see this as a way to
>> improve boot reliability, if someone needs 64 drives for root and
>> boot, they need to read a few essays on filesystem
>> configuration. However, I'm aware that there are some really bizarre
>> special cases out there.
>
> There's LVM. If you have to keep root out of the VG just because
> people say so, you lose lots of benefits from LVM, such as being able
> to grow root with the system running, take snapshots of root, etc.
>
But it's MY system. I don't have to anything. More to the point, growing
root while the system is running is done a lot less than booting. In
general the root f/s has very little in it, and that's a good thing.
--
Bill Davidsen <davidsen@tmr.com>
Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.
prev parent reply other threads:[~2006-08-02 16:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-30 6:56 let md auto-detect 128+ raid members, fix potential race condition Alexandre Oliva
2006-07-30 19:41 ` Andrew Morton
2006-07-30 20:56 ` Alexandre Oliva
2006-07-30 21:21 ` Andrew Morton
2006-07-30 23:20 ` Neil Brown
2006-07-31 16:34 ` Helge Hafting
2006-07-31 20:27 ` Alexandre Oliva
2006-07-31 21:48 ` David Greaves
2006-08-01 2:20 ` Alexandre Oliva
2006-08-01 8:28 ` Michael Tokarev
2006-08-01 21:24 ` Alexandre Oliva
2006-08-01 1:19 ` Neil Brown
2006-08-01 2:35 ` Alexandre Oliva
2006-08-01 3:33 ` Alexandre Oliva
2006-08-01 20:46 ` Alexandre Oliva
2006-08-02 6:37 ` Luca Berra
2006-08-01 17:40 ` Bill Davidsen
2006-08-01 21:32 ` Alexandre Oliva
2006-08-02 6:47 ` Luca Berra
2006-08-02 16:47 ` Bill Davidsen [this message]
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=44D0D718.5050505@tmr.com \
--to=davidsen@tmr.com \
--cc=akpm@osdl.org \
--cc=aoliva@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.