[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 16:38 -0400, Drew from Zhrodague wrote:
> I have just the opposite experience, which has me choose to use 
> one big / partition.

What happens when /var corrupts, eats up all your disk space, etc???
What do you do about /tmp and /var fragmentation on your volume?

> Disks are cheap,

Then why not get bigger and segment bigger slices?

> and if you're using a journaling FS atop a RAID, there is little
> chance of corruption -- at least that I've seen.

Whoa!  Whoa!  Whoa!

Q:  What is the purpose of meta-data journaling?

A:  _Mitigate_ the time it takes to put the filesystem into a
    "clean" state.

I stress the word "mitigate."  Why?

Q:  Which is _better_ for ensuring a filesystem is consistent?
  1.  Full fsck
  2.  Full data journaling
  3.  Meta data journaling

A:  1, period -- journaling does _not_ guarantee consistency
Almost as good:  2, with NVRAM as your full data journaling

Journaling is _only_ "mitigating" the risk of an inconsistent
filesystem.  _Only_ a full fsck _guarantees_ it.  ;)

> In fact, I don't think I've ever seen a corrupted UNIX filesystem 
> yet.

I have, plenty of times.
/var is especially a PITA.
And it, along with /tmp, fragments like hell.  ;)

You can also have to deal with the fact that hardware does have issues.
Even CRC checks are "mitigating" risk, not eliminating it.  ;)

> I just get annoyed when a 2G /var patition is full

2GB?  2GB?  For /var?  Where you been?  ;)
Both APT and YUM use /var/cache.  Not enough.

Make a stock 4-8GB /var.

Beyond that, further segment /var further into /var/www for web servers
(ideal from a security standpoint), /var/ftp for FTP servers (again,
security enhancing), /var/mail for mail servers, /var/spool, /var/lib/*,
etc... as appropriate.

Use volume management as necessary to allocate additional when needed.

> and I have to put symlinks all over.

Again, why not just mount more filesystems in it for the subdirectory
that needs it?  E.g., if you're filling up /var/cache with APT or YUM
packages, then allocate a /var/cache filesystem.

I _always_ reserve 20-30% of any LVM for this reason, to temporarily
assign storage as necessary.  This isn't just me talking, but most
people used to volume management on various UNIX platforms.

I never see people end chuckling when they see Linux sysadmins who start
touching enterprise HP/UX, Solaris and other platforms and go, "What is
this 'partition table'?  Why aren't you using all space?  Etc..."

> A big / partition means that is almost *never* an issue,

What if your journal replay fails and you need a full fsck?

One "big" filesystem under consistency check, instead of only one
smaller one of many.

I've had, more than once, one user filesystem that was inconsistent.  I
needed to bring the server up ASAP, so the other users on other
filesystems could work.  I don't like being rushed into something like a
"fsck -y".  I brought up that server, sans that one filesystem, so only
that one filesystem wasn't available for users could be calmly addressed
with a "fsck -n" and analyzed proper before just throwing "fsck -y".

> especially if you have to install wacky software, or have 5 copies of
> some package.

Allocate storage as appropriate.  That's why volume management is quite
ideal.

Red Hat wouldn't be using LVM by default in its Anaconda installer if
volume management wasn't already a very, very common, production UNIX
practice.


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