[wplug] Re: MD on atop of LVM (or LVM2's native RAID), instead of LVM on top of MD -- WAS: Install Question

[Bryan J. Smith]

On Wed, 2007-07-25 at 17:36 -0400, Drew from Zhrodague wrote:
> Same thing that happens when the power supply fails, SAN goes 
> down, or the core switch gives birth to Cthulu: box goes down.

Really?  Mine don't.  /var may fill up with logs, but it _hardly_ brings
down my boxen when it does.

Now when /tmp fills up, that's a bit more of a concern.  Of course,
there is monitoring and other considerations.

> This is why we have redundant servers, and our common protocols 
> support multiple hosts (DNS, SMTP, etc), plus things like load-sharing.

Ahhh, yes, agreed.  But that gets quite costly when you move beyond just
DNS, SMTP and HTTP.

Like when you have database and file servers.  Now you should try to
implement true failover with those as well, but it does get cost
prohibitive.

And what about when its your KDC?

> Many many many many places durring my career. My resume reads like 
> a list of dotcom losers!

FYI, that was _not_ a question of your career, it was rhetorical.  ;)

I just wondered why anyone would make 2GB /var filesystem with the
common size of APT or YUM fed distros these days.

> If you log into a FedEx Ground server, and do a df, it produces a 
> partition list that scrolls off the screen. For a minute or two. All 2G 
> partitions. That is what happens when mainframe people administer UNIX.

Sounds like ignorance of APT or YUM on their part.  I've run into that
too.

But that's where you come to the rescue!  You allocate and mount
another /var/cache.

Just because they are allocating in ignorance doesn't mean you do.  You
sound like an experience professional that knows how much /var/cache
needs.

> *Poof!* too small for a public webserver.

Hence why I have a separate /var/www!
Actually, it's /srv/www in keeping with FHS 2.3.

> Wow, how bizarre. How is having a seperate partition for your 
> htdocs good for security?

Yes!

Have you been through Apache's default security model (including not
crossing filesystems, or the explicit declarations)?

Furthermore, you can "lock-down" options by filesystem mount, such as
preventing exec and other things.

Add SELinux into the mix and it's quite nice.  ;)  

> I haven't seen any Suns in production in a while.

Solaris/Opteron is quite nice.

> I remember their install instructions had some sort of formula for
> determining the proper size of the swap partition (which was
> actually /tmp).

Er, yes and no.  You can mount vm into /tmp, but you don't have to.
Linux has this option as well.

> Otherwise, their disk partitioning scheme is cartoon-rediculous.
> Slapstick wacky Sun disklabel.

Whoa!  You mean its disk labels are not good?  Furthermore, you _do_
understand why slice 2 is the entire geometry, correct?

[ Imagine if we had that in PC space! ]

> I've seen lots of suns have disks hanging off the thing like an 
> old Mac kept alive by 8 or 9 50M disks, presumably because they ran out of 
> space on their various partitions.

Again, just because they are allocating in ignorance doesn't mean you
do.  ;)

> You gotta remember that a good UNIX machine will live out it's 
> life, and be repurposed several times after that.

Er, um, you may work in the web space where you rotate new servers in
every 1-2 years.  I work in the engineering space where a good
authentication, database and file server may be in use 5-7 years.  ;)

> Sometimes it requires more software, more data, or more users.

And that's why you use volume management to dynamically allocate
additional space when you need it.

> If you condemn yourself to running out of space, I guess it is your
> replacement that will have to deal with it!

How can I "condemn" myself or my replacement to "running out of space"
when I use a solid slicing approach combined with dynamic volume
management?

> Then again, disks are cheap, and large. A / partition makes 
> things easy for me to set it up, and not have to think about it again.

What about when /var runs away?  (repeat prior discussion)

> Of course, now we actually have SANs...

And do you make "one big partition" for them too?

Segmentation, volume management, dynamic allocation.

There are bad UNIX administrators as well, but they don't last.  ;)

-- 
Bryan J. Smith         Professional, Technical Annoyance
mailto:b.j.smith at ieee.org   http://thebs413.blogspot.com
--------------------------------------------------------
        Fission Power:  An Inconvenient Solution