Meino Christian Cramer schrieb:
From: kashani <[EMAIL PROTECTED]>
On a home system I'd be tempted to have one big partition where LVM
would buy you nothing.
Pros: However at work I run a number of dev boxes. You can tell a
programmer many things, but you can't tell him where to put his files.
Using LVM I allocated 40GB of an 80GB drive and now can grow /var /tmp
/opt and /home as needed. I run the whole thing on top of a software
RAID 1.
Cons: I briefly blew up LVM by not rebuilding lvm after device-mapper
changed... or it might have been the other way around. Had to chroot,
figure out how to mount LVM, and then rebuild a few packages. Took maybe
60 minutes or so since I had to manually setup the RAID 1 first.
I guess the con is more stuff to remember to build into your kernel and
watch for updates on.
kashani
--
[email protected] mailing list
Thanks a lot for your reply, kashani ! :)
Hrrrmmm...I am not a native English speaker...I am not whether I
understood your first sentence correctly...
Did you mean: On a home system it is no advantage to use LVM
Yes, because he'd give the (IMO *extremely* *bad*) advice to use
just one huge filesystem for everything.
I very much disagree with that. IMO, even on home systems it makes
a lot of sense to use multiple file systems.
What's about fragmentation of data, when using LVM ?
It doesn't have anything to do with LVM.
You're mentioning a "problem" of LVM: With LVM, the Logical Volumes,
and thus the filesystems on top of those LVs can be fragmented (and
very often will be). This happens, when a LV will be resized. Reason:
Suppose two LVs are created. Those 2 LVs are adjacent. Then the 1st
LV (at the beginning of the VG) is to be extended (made bigger). This
will cause the first part of the 1st LV to be in front of the 2nd
LV and the 2nd part of the 1st LV will be after the 2nd LV.
Alexander Skwar
--
Never commit yourself! Let someone else commit you.
--
[email protected] mailing list
