Date: Mon, 22 Mar 1999 14:36:08 -0500 From: Doug Ledford <dledford@redhat.com> To: Carlos Carvalho <carlos@fisica.ufpr.br> Cc: AIC7xxx@FreeBSD.ORG Subject: Re: SOFTWARE-RAID-TIPS (was: Adaptec 7890 and RAID portIII RAID controller Linux Support) Message-ID: <36F69BA8.364DA923@redhat.com> References: <Pine.LNX.4.04.9902241451370.23862-100000@maxwax.doghouse.com> <36D582F5.AC7405E3@redhat.com> <14069.31640.589330.961337@hoggar.fisica.ufpr.br>
next in thread | previous in thread | raw e-mail | index | archive | help
Carlos Carvalho wrote:
> OUCH!! This is VERY BAD news indeed :-( What you recommend is
> virtually impossible. If you have several partitions to put in the
> raid it'll cause an unacceptable loss of space... If you have to put
> /, /usr, /var and /home in the raid, how many disks will you need?
This isn't as much of a problem as you make it out to be. I've read forward
on the list to see the other various points made about this issue, and I'll
try to address most of them here. First, breaking up partitions is primarily
a holdover from the early days of 100MB disks like someone else mentioned. I
see little reason to perpetuate it. The issue of quotas was brought up.
That's a moot point. With quotas you can control on a per filesystem basis,
but for /usr, /var, and / (excluding /tmp) the space you want to give someone
is 0. Furthermore, they shouldn't have write permissions in those areas
anyway, so the quota is totally irrelevant. So, you give quotas on /home and
/tmp areas. If you split your system up to /, /tmp, and /home, then you've
covered what you need. Make / about 1gig to hold /usr compfortably, make /tmp
a few hundred MB to keep people from abusing it, and give the rest to /home.
If you are really concerned about /var, then make a /home/var and symlink /var
to /home/var. That way log files won't kill your / partition. Now, if some
of this seems odd, realize this is my answer to "We don't want to spend tons
of extra money on extra disks". For a server being built on a typical "IBM"
class budget, then you'd get one disk for / and /tmp (as well as swap),
another for /opt if needed, and then put your big stuff on dedicated RAID
arrays. Now, having gone through all that, I still prefer a large / raid
array for the majority of systems that are using it. A large number of them
are dedicated database/web servers or ftp or USENET news servers where /home
isn't an issue, nor is mount options since the machines are not generally
accessible. Large multi-user machines with lots of shell accounts are an
exception to the rule I think, and very well might warrant a different setup.
> My option is to spread each partition on as many disks as possible,
> using raid5. This maximizes space, and is also good for speed if you
> use a small chunck size so that most operations are spread through
> several disks that are accessed simultaneously.
>
> >3. In my case, I've created a RAID array that's used as my /
> >partition, so I had to have
> >a stand-alone /boot partition to store the kernel in. Anyone who
> >attempts to do this exact setup, I *strongly* recommend that the
> >/boot partition be at least 100MByte in size and that you actually
> >install a minimal installation on the /boot partition (as a bare
> >minimum, copy the /etc /bin /sbin /lib directories onto the /boot
> >partition, but in my case, I've also selected certain stuff from
> >/usr/bin /usr/lib and other directories to go over there as well).
> >This way, if anything does happen to your raid array, you have the
> >raidtools installed on your /boot partition, you can boot the kernel
> >with the root= command line switch, boot into a working rescue set,
> >then fix the raid array from there. It's much faster and easier than
> >rescue disks and since you have to have this partition for LILO
> >anyway, you might as well make effective use of it :)
>
> This is a minor point, but I don't think this is useful with the
> current versions of the code. If you manage to load the kernel, it'll
> do everything for you, even if the array is out of sync, disk numbers
> have changed, etc. So all you have to do is load the kernel. I think a
> small partition containing just lilo and the kernel is enough. If this
> disk fails you can use a floppy with syslinux and the machine is back.
> This may need manual intervention, but if the boot disk fails the
> machine won't boot automatically anyway.
Correct. But then again, I've been working with the latest code and on
occassion I've had to coerce it back into functioning after having two drives
marked bad when I really knew they weren't. I managed to save all my data,
but what I had to do was some raidhotadd/remove magic to convince the kernel
which drive needed rebuilt and what parity needed rebuilt. That makes the
partition useful if for no other reason. However, it's also useful when
testing since I keep a complete kernel tree there and can recompile with fixes
if need be without the RAID being alive.
> What if the raid partitions don't work even with the kernel loaded?
> Then you're lost, and all the software listed above won't help you. If
> the kernel can't start the partitions, nothing will do it.
Not true. You just have to know how to manipulate the new RAID code into
thinking what you want it to think :)
> You have to
> re-install from backup if you use raid5. With raid1 you can mount the
> partition directly, so you don't need all the stuff on the boot one.
>
> I'll redo the raid here to include one more disk, and in the new
> partition scheme I won't even copy the boot partition in more than one
> disk. I'll use Doug's idea of using the other disks for swap.
>
> I agree with the other points.
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe aic7xxx" in the body of the message
--
Doug Ledford <dledford@redhat.com>
Opinions expressed are my own, but
they should be everybody's.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36F69BA8.364DA923>