Re: to lvm or not to lvm?
Default User wrote:
On Fri, 2007-04-20 at 19:42 -0400, Douglas Allan Tutty wrote:
On Fri, Apr 20, 2007 at 10:37:35AM -0500, Default User wrote:
After installing fresh Etch with encrypted lvm (all except /boot), per
non-expert install, I am reconsidering whether lvm is a good idea. It
works fine - now - but what if it stops working?
I really do like the ability to resize my partitions as needed (the
layout that seemed fine upon install can really look stupid 6 months
later). But not at the price of my data.
And does encryption of lvm partitions unnecessarily complicate matters,
especially recovery? Would just an encrypted swap partition only be
a fresh install is a rare opportunity to do things right, so I try not
to squander it.
Interestingly I've been thinking about this recently as I migrate my
home servers, firewalls, etc.. to Etch. It occurred to me that since
one of the main reasons we partition harddrives on a server is so that a
problem causing one partition to fill, won't necessarily cause the whole
system crash, given this, what would be really cool would be to
partition the system at install time using a slightly mean, but
granular, best guess layout  so things should fit in their partitions
without too much wasted space, then configure each partition as one
mount point on one logical volume consisting of one physical volume 
and then partition up the rest of the drive in 1GB chunks that sit in a
pool of unused logical volumes so they can be assigned to any mount
point when needed, preferably automatically.
You could have the system email you whenever a gig is added to a mount
point, so when you get attacked, mail bombed or have a program crash in
a noisy log filling way, the system doesn't go down, it keeps tacking
chunks on to the back of the relevant logical volume and emailing/SMSing
you each time, you could then ssh in, figure out what's wrong, fix it,
and then, assuming you used a file system that can be contracted while
online,  clear the relevant logs, mail, whatever, shrink the file
system and return the now unused chunks to the pool.
I don't know if this has been done already, but it could all be done
today with shell scripts,  which would make it easy to have rules
about how much any one partition can grow, and extend it so if you've
got an email address that collects spam it could purge that, or
automatically purge the syslog of dhclient messages,  run logrotate
One hassle is it would be a PITA to do all that partitioning by hand, it
would be much better handled by a script at install time.
 meaning have a lot of partitions of appropriate sizes, /var,
/var/tmp, /var/mail, /var/log, /var/cache...
 at least most of them, not /boot or any others you're very confident
won't grow beyond the initial partition size
 it would be nice to have one that doesn't require 30% free space to
reduce fragmentation but...
 although we could use some loopy script running df to monitor mount
point utilization, there must already be some much more efficient daemon
for monitoring and emailing which could be made to run a shell script
 my damn ADSL router renews my IP every 30 seconds
Garrr, do your bit for global warming, become a pirate, you can "borrow" my copy of Windows 95 if you want.