* Expandable raid
@ 2008-09-13 15:29 Bill Davidsen
2008-09-14 11:16 ` Peter Grandi
0 siblings, 1 reply; 3+ messages in thread
From: Bill Davidsen @ 2008-09-13 15:29 UTC (permalink / raw)
To: Linux RAID
I am setting up a system with five drives. Initially two will be for the
system and three for other uses. In about 4-6 weeks the three will be
added to the original two. Thoughts on picking a raid config to make
this easy? I would like to use raid-10, but I don't see a way to grow it.
Kernel will be initially FC9 (whatever is shipping in the next few
days), but a kernel.org 2.6.27 will be going in shortly in hopes that
the changes to MTRR handling will allow a PAE kernel to use all of 8GB
memory in 32 bit mode.
--
Bill Davidsen <davidsen@tmr.com>
"Woe unto the statesman who makes war without a reason that will still
be valid when the war is over..." Otto von Bismark
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Expandable raid
2008-09-13 15:29 Expandable raid Bill Davidsen
@ 2008-09-14 11:16 ` Peter Grandi
2008-09-14 16:29 ` Bill Davidsen
0 siblings, 1 reply; 3+ messages in thread
From: Peter Grandi @ 2008-09-14 11:16 UTC (permalink / raw)
To: Linux RAID
> I am setting up a system with five drives. Initially two will
> be for the system and three for other uses. In about 4-6 weeks
> the three will be added to the original two.
What does "added" mean here? Physically? Logically? If logically,
in what way? And what's the starting point? If you start with 5
drives, why configure them initially as 2 arrays, and then merge
later into 1 array? The exact array shapes involved matter.
> Thoughts on picking a raid config to make this easy? I would
> like to use raid-10, but I don't see a way to grow it.
What's "this"? Do you want to end up with a 5-drive array? If
so, where are you going to put the boot filesystem (most BIOSes
require single drive boot filesystems) unless it is a 5 drive
RAID1? In which case, growing is easy :-).
More generally, my usual story: growing an array is a dangerous
and slow operation. Backup and restore is usually a lot faster,
results in a better physical to logical layout, and safer (and
one should backup anyhow before growing).
BTW I was just looking at his home page for other reasons (NFSv4)
and noticed this:
http://neil.brown.name/hg
"LaFS Log Structured File system for Linux - VERY alpha
Neil Brown 7 weeks ago RSS".
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Expandable raid
2008-09-14 11:16 ` Peter Grandi
@ 2008-09-14 16:29 ` Bill Davidsen
0 siblings, 0 replies; 3+ messages in thread
From: Bill Davidsen @ 2008-09-14 16:29 UTC (permalink / raw)
To: Peter Grandi; +Cc: Linux RAID
Peter Grandi wrote:
>> I am setting up a system with five drives. Initially two will
>> be for the system and three for other uses. In about 4-6 weeks
>> the three will be added to the original two.
>>
>
> What does "added" mean here? Physically? Logically? If logically,
> in what way? And what's the starting point? If you start with 5
> drives, why configure them initially as 2 arrays, and then merge
> later into 1 array? The exact array shapes involved matter.
>
>
Means I have five drives and need three for a project so they can't be
part of the original system configuration. I will put system on two, and
add the others after the project requiring them is complete.
>> Thoughts on picking a raid config to make this easy? I would
>> like to use raid-10, but I don't see a way to grow it.
>>
>
> What's "this"? Do you want to end up with a 5-drive array? If
> so, where are you going to put the boot filesystem (most BIOSes
> require single drive boot filesystems) unless it is a 5 drive
> RAID1? In which case, growing is easy :-).
>
I always put the boot filesystem on raid1, over the first two drives (as
seen by the BIOS). That way if one fails the BIOS boots the other. Once
the system is up I can have the rest of the data as I want it. Generally
a 200-200MB boot partition is adequate, with MBR written to both drives.
> More generally, my usual story: growing an array is a dangerous
> and slow operation. Backup and restore is usually a lot faster,
> results in a better physical to logical layout, and safer (and
> one should backup anyhow before growing).
>
If I had the resources for backup space I would have just put more
drives in the box, used a bigger box, etc. I'm looking for proposed
solutions to the problem I have, rather than ways to avoid having the
problem if I had resources I don't have.
> BTW I was just looking at his home page for other reasons (NFSv4)
> and noticed this:
>
> http://neil.brown.name/hg
>
> "LaFS Log Structured File system for Linux - VERY alpha
> Neil Brown 7 weeks ago RSS".
>
Not really very descriptive, the filesystem which interests me at the
moment is the one Compaq released from their UNIX on Alpha o/s, Tru64
IIRC. It has the advantage of having been in enterprise use for about a
decade, and gets good marks from people I actually know and trust.
Compared to Reiser4, ZFS, and even XFS (from what I hear) it seems to
offer good real world performance without guru-level tuning and initial
setup.
Always interesting, of course.
--
Bill Davidsen <davidsen@tmr.com>
"Woe unto the statesman who makes war without a reason that will still
be valid when the war is over..." Otto von Bismark
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-09-14 16:29 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-13 15:29 Expandable raid Bill Davidsen
2008-09-14 11:16 ` Peter Grandi
2008-09-14 16:29 ` Bill Davidsen
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).