[aklug] Re: Since we're talking about LVM

On Mon, 6 Apr 2009, Thomison, Lee wrote:

> Since we're talking about LVM, and I'm in learning mode, I've couple of que=
> stions been kicking around in the back of my head for a while now. Perhaps=
> it's time to kick them out...
>
> 1. Putting /boot on it's own partitition outside the volgroup I understand=
> , at least until grub catches up, and maybe even after that for recovery op=
> tions, etc. But I've noticed that everyone is putting their swap inside th=
> e volgroup. This puzzles me, because I've always understood that the swap =
> system itself was optimized to work across multiple drives directly; that's=
> why you didn't stripe swap. So why is swap being included in a volgroup r=
> ather than outside on their own partitions as has been practice in the past=
> ?

This comes down to a question of performance. If you're on a system that
regulary dives deep into swap then you probably would want to remove the LV
abstraction layer. Personally, that's almost never an issue because I try
to spec hardware so that swap is only lightly, if ever, used. If you don't
have the spare RAM, though, you can still tell LVs to stripe across PVs and
that gives you the flexibility of resizing it as needed over time.

It all comes back to how good you are at prognostication. If you use
partitions and you're wrong, you've got a big problem on your hand. Best
case scenario says that you can add more disk and another partition, but
what happens if you're out of internal drive bays, or worse, running a
SATA/IDE system? You might be looking at needed another HBA as well, then.

Doing it as an LV just makes things simpler, especially if you have the
excess storage already in the VG.

> 2. I have always been in the habit of putting /home (and often /var) on th=
> eir own partitions and/or raidgroup (used to be raid5, is now raid10 with 4=
> drives). On the one hand I can see that having more than one volgroup wou=
> ld seem to be kind of useless if not actually silly because of the argument=
> for being able to reallocate space as and where needed. On the other hand=
> , it just seems iffy to include /home in the same volgroup as everything el=
> se. Is there something I'm missing here? =20
>
> I guess let me rephrase the question from a different eye...why would anyon=
> e ever use more than one volgroup on a machine?

I use multiple VGs frequently, and there's plenty of good reasons for doing
so. On instance is for two machines in a hot-failover configuration. You
put your data on a VG containing only PVs from a SAN. If the master goes
down, the backup can activate the VG, launch the services, and do IP take-
over.

Less frequently, you may just have a big external disk (USB or
firewire-attached) that you don't want to use as one giant filesystem (or
limit yourselves to the partition table), and it's not always attached. A
data VG makes perfect sense here, as well.

> 3. What are the thoughts about EVMS? Why is LVM gaining traction and EVMS=
> is not?

EVMS is arguably superior in some ways, but the kernel devs threw their
support behind LVM2. I don't know the inner politics, but if I had to guess
it's probably because LVM2 was quicker to adapt and leverage the whole
device-mapper evolution, something that LVM1 & EVMS preceded. Leveraging a
common infrastructure that could be used by multiple code bases always gains
favor in the eyes of the kernel devs.

         --Arthur Corliss
           Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Mon Apr 6 09:23:47 2009