Re: [SLUG] Partition type question

From: Ian C. Blenke (icblenke@nks.net)
Date: Tue Sep 10 2002 - 17:59:12 EDT


On Tue, 2002-09-10 at 17:38, Matt Miller wrote:
> On Tue, 2002-09-10 at 14:14, Jim Wildman wrote:
> > Lots of geeks, lots of paradigms...
>
> Definitely. :)
>
> > Similarly /, /boot, will get their own, and maybe /usr/local. /home
> > and /opt definitely separate. The idea is create 'firebreaks' so that
> > when something bad happens, the damage is limited.
>
> This is true, but as inexpensive as most disks are today, RAID provides
> all the "firebreaks" you need. For home, one can purchase a decent
> motherboardŽ with a built-in IDE RAID (1 or 0) controller for less than
> $125. For the 99.999999% uptime requirements in many businesses, a
> combination of RAID and HA clustering fits the bill.

Even /boot is wearing out its welcome. With lba32 support in lilo, and a
grub that is likewise geometry friendly, having a small partition below
the 1024 cylinder mark for a kernel is simply no longer needed. Granted,
I still do it too, but as times progress filesystems come and go.

3ware 6410 escallade cards are going for ~$100 now, and the hardware
RAID5 is respectible (hey, they're cheap ;)

> > The backup issue has been a mute point for years, every since tar (and
> > its cousins, derivatives and replacements) learned to traverse file systems.
>
> Agreed, but it helps explain why a lot of "old skool" Sys Admins
> strictly adhere to partitioning with a specific layout.

I've met "old skool" admins that throw their nose up in the air when I
start explaining my disk layouts and reasoning. This is particularly
true when you start dealing with old-school DBAs that like dealing with
"spindles", even though modern SANs abstract the spindle away from the
host machine and most volume managers like Veritas negate the need to
care. Sure, you want to avoid head contention if you can help it, but
when you have 320G on a harddrive and only one head per platter on a
couple of platters (all on the same arm anyway, already beyond the reach
of the admin), there's going to be a head contention issue - you simply
have to make up the seek penalties with caching strategies. Why do you
think they ship 8M caches on large IDE harddrives today? Drives
disregard cache flush imperatives from the bus to improve write
performance, RAID controller cards often do the same from the host OS,
it gets to the point where you simply have to throw a gob 'o RAM at
cache anyway, stripe the drives, and divvy up the volumes from virtual
pools of disk space.

But I digress..

- Ian C. Blenke <icblenke@nks.net> <ian@blenke.com>
http://ian.blenke.com



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 19:13:33 EDT