[PLUG] Backing up to DVD?

[Chris Jantzen]

First off, sorry about the tight space/hardware thing. I know how it feels.

On Wed, Dec 03, 2003 at 03:34:13PM -0800, Elliott Mitchell wrote:
> > Plus LVM lets you expand and rearrange volumes live (of course, your
> > *filesystem*, not volume, will need to support expansion as well for it
> > to be actually useful--another reason I like reiserfs, it does this
> > instantly and without preperation, in a logged filesystem) and at will--
> > no reboot after fdisk. No need to tar-pipe or dump/restore your files
> > around new drive layouts: I just move the PE's for volumes I want on
> > new arrays or drives from the old drive to the new drive--it's live
> > and transparent.
> 
> Two issues, first is that reliability one. More complexity, more chances
> for data-corrupting bugs. Also the need for more hardware because more
> complexity generally means slower.

I've never had any issue with Linux LVM except earlier versions stalling
the system excessively during a volume move on a heavily loaded live
server. Additionally, EVMS is ported from use in AIX on zSeries mainframes,
et. al. I, personally, first ran into LVM on an HP-UX mini I assisted in
running ... hmmm ... thinks ... 11 years ago? The concept is well-tested
and a core part of "enterprise".

Implementation bugs are just as bad as any other bug, really. Early 2.5
had IDE data corruption bugs. Versions of ext3 have had corruption bugs
(I lost the journal on my laptop, for example). Potential LVM bugs aren't
any more "special".  You always want to play it safe when upgrading your
kernel or doing any kind of major build. And see if new techniques or
methods you're looking into adopting are robust in design and concept.

> Second, perhaps I should do more research on the issue, but my last read
> of LVM had indicated you didn't get control over where volumes physically
> resided. You gave it instructions, but you only had logical control, not
> physical.

You can pvmove extents to any device you want. You can even initially
create volumes specifically on any physical device of your choosing.

> > Also, if your bootloader can load the initrd, then you never, ever need
> > to worry about what physical disk contains your system. LVM will
> > autodetect the devices that form the volume groups and let the system
> > boot from there. I've gone back and forth between md, ide, scsi, and
> > scsi raid without ever *touching* my /etc/fstab or kernel root
> > parameter.
> 
> I build custom kernels, so I don't worry about initial ramdisks (on the
> one machine I don't worry about modules either, deliberatly static
> kernel).

No, you need userspace tools to detect and activate the volumes because
the kernel doesn't have the bloat to walk the disk structures to autodetect
the major/minors for the volume block devices. This scenario will become
the norm, more than the exception for many subsystems with 2.6. (Although
2.6 makes initrd's even more transparent.)

> Which leaves the sole concern being loading the kernel. Even
> LILO can load from beyond the olde limit, so I guess that is no longer a
> concern. 

Well, yes, I do have a fixed, tiny /boot partition. :-)

> You don't need LVM though to remove the need to modify fstab,
> you could mount filesystems by label for a long time (long time in this
> case meaning even Debian stable can do it).

/me investigates.

Ah. Didn't know that had gone beyond "just ext2". (I think the last time
I looked at that must've been around RH6.2) Still, mounting /dev/vg0/root
instead of the Linux-specific label syntax "feels" more portable to me
across UNIXen. To me.

> > Like I said, there is almost no reason "you" (i.e., in the general sense)
> > shouldn't be running LVM right now. Like backups are insurance against
> > failure, LVM is "insurance" against future configuration changes
> > ("failure to think"? :).
> 
> Then again so is good planning, and experience. I know what I'm doing so
> I don't yet need LVM (or EVMS). Still you're likely correct, good for
> people who don't know.

I'm just pointing to the "yet". Better to start now and have it at your
fingertips when "yet" comes, than try to revamp everything. Kind of like
backups: you aren't *planning* to have a system failure, but it's a
possibility, so it's good to have your options open. Although one could
say, I'm just encouraging better planning in this regard, now that I
look at it. :-)

Maybe my sense of perspective is warped: building large storage servers,
using NetApps, etc where having an LVM is like air and water to me. :-)
I still maintain that you should start with one as your initial install
as long as you're doing anything more complex than "firewall", "web
appliance", or "email pop toaster". Although I admit your language of
"reduce complexity" does sound like you tend towards this field.

-- 
chris kb7rnl =->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.pdxlinux.org/pipermail/plug/attachments/20031204/d5d72788/attachment.asc>