6:36 p.m.
I have been heard from multiple sources that LVM will be used by
anaconda when using automatic partitioning. I think this is a very bad
idea. It breaks the KISS(Keep it simple stupid) principle. I have
personally used LVM in the past and currently use software raid. Both
are powerful and wonderful features, but in most cases are overkill,
make things more complex, and make life hell when something like grub or
init scripts break.
2:21 a.m.
On Thu, 7 Oct 2004 09:36, Nathan Grennan <fedora-devel-list(a)cygnusx-1.org>
wrote:
I have been heard from multiple sources that LVM will be used by
anaconda when using automatic partitioning. I think this is a very bad
idea. It breaks the KISS(Keep it simple stupid) principle. I have
personally used LVM in the past and currently use software raid. Both
are powerful and wonderful features, but in most cases are overkill,
make things more complex, and make life hell when something like grub or
init scripts break.
Not using LVM makes things more complex if the partition sizes you choose at
install time end up not matching the type of data you install. That then
leads to doing nasty things like moving trees of files to a different file
system and having sym-links between them which among other things causes
problems with SE Linux.
In many ways LVM is the simple way of doing it!
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
3:24 a.m.
On Thu, 2004-10-07 at 17:21 +1000, Russell Coker wrote:
Not using LVM makes things more complex if the partition sizes you
choose at
install time end up not matching the type of data you install. That then
leads to doing nasty things like moving trees of files to a different file
system and having sym-links between them which among other things causes
problems with SE Linux.
Yes, at a higher level it does make things simpler. But at a lower level
it makes things much more complex, and the lower level will come out
when something breaks. In most cases you could solve the running out of
disk space problem by just making everything one big partition. I don't
have a problem with LVM, I just have a problem with as the default,
which will effect the newbies more than anyone else. As for SELinux, I
think it needs a lot of work before it is ready for prime time.
I think the best thing to do if developers are determined to go down
this road is to make it a boot option or something, but not make it the
default for now. All the cases need to be covered first. Does this work
with rescue mode? Will it cause any issues with users trying to
reinstall grub with grub-install?
8:56 a.m.
On Thu, 2004-10-07 at 01:24 -0700, Nathan G. Grennan wrote:
Yes, at a higher level it does make things simpler. But at a lower level
it makes things much more complex, and the lower level will come out
when something breaks. In most cases you could solve the running out of
disk space problem by just making everything one big partition. I don't
have a problem with LVM, I just have a problem with as the default,
which will effect the newbies more than anyone else. As for SELinux, I
think it needs a lot of work before it is ready for prime time.
I think the best thing to do if developers are determined to go down
this road is to make it a boot option or something, but not make it the
default for now. All the cases need to be covered first. Does this work
with rescue mode? Will it cause any issues with users trying to
reinstall grub with grub-install?
In taking a look at my fairly fresh laptop install (network install of
rawhide circa 9/25 or so), it partitioned my 30GB drive into a
100MB /boot partition and the rest as LVM. My /etc/fstab entries look
like:
/dev/VolGroup00/LogVol00 / ext3 defaults
1 1
LABEL=/boot /boot ext3 defaults
1 2
/dev/VolGroup00/LogVol01 swap swap defaults
0 0
The grub argument appears to be a non-issue, my boot partition is not
part of LVM. Doesn't look too complex to me. Granted, I may not be
able to use that boot floppy with a 2.2.0 kernel from 8 years ago to
rescue the system since it probably won't have LVM tools on it, but the
Fedora rescue CD or Knoppix will probably work just fine.
Additionally, during the installation I just did the auto-partition
option as always and Anaconda did all the hard work setting everything
up for. From my end-user perspective, it's not more complex at all. I
also like the thought of being able to upgrade to a larger drive in the
future by simply joining it to the group, moving all the data and
resizing it. Pretty slick.
--
David Hollis <dhollis(a)davehollis.com>
9:49 a.m.
On Thu, Oct 07, 2004 at 09:56:06AM -0400, David Hollis wrote:
My /etc/fstab entries look like:
/dev/VolGroup00/LogVol00 / ext3 defaults
1 1
This reminds me... Is there any particular reason the default names
of volume groups are "VolGroupXX" instead of something simpler like
"vg00"? Ditto with logical volumes.
HPUX (and the LVM man pages, last I looked) uses vgXX and lvolX. I
personally prefer to be a bit more consistent and use vgXX/lvXX.
Either way, I find short, lowercase names to be much easier to type,
look at, etc.
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)398-3000 Mobile: (618)567-7320
10:01 a.m.
Once upon a time, Steven Pritchard <steve(a)silug.org> said:
On Thu, Oct 07, 2004 at 09:56:06AM -0400, David Hollis wrote:
> My /etc/fstab entries look like:
>
> /dev/VolGroup00/LogVol00 / ext3 defaults
> 1 1
This reminds me... Is there any particular reason the default names
of volume groups are "VolGroupXX" instead of something simpler like
"vg00"? Ditto with logical volumes.
I typically make the volume group match the hostname and the logical
volumes match the filesystem (so the system "flea.hiwaay.net" has
/dev/flea/usr, /dev/flea/tmp; / is /dev/flea/root). Making the volume
group distinct is good if you have a need to move a drive from one
system to another (having two VolGroup00 is NOT good), and naming the
logical volumes sensible just makes it much easier to tell what is what.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
10:17 a.m.
On Thu, 2004-10-07 at 09:49 -0500, Steven Pritchard wrote:
On Thu, Oct 07, 2004 at 09:56:06AM -0400, David Hollis wrote:
> My /etc/fstab entries look like:
>
> /dev/VolGroup00/LogVol00 / ext3 defaults
> 1 1
This reminds me... Is there any particular reason the default names
of volume groups are "VolGroupXX" instead of something simpler like
"vg00"? Ditto with logical volumes.
Mostly to make it clearer at a glance for the user who's not as familiar
with LVM as to what might be going on.
Jeremy
3:39 a.m.
On Thu, 2004-10-07 at 01:36, Nathan Grennan wrote:
I have been heard from multiple sources that LVM will be used by
anaconda when using automatic partitioning. I think this is a very bad
idea. It breaks the KISS(Keep it simple stupid) principle. I have
personally used LVM in the past and currently use software raid. Both
are powerful and wonderful features, but in most cases are overkill,
make things more complex, and make life hell when something like grub or
init scripts break.
How exactly would LVM make things complex? Shuffling data around when
you need to have more space than your physical partition can hold is
complex, having your system setup in a way that you can easily(*) extend
filesystems or move them from physical disks on the verge of breaking to
new disks(**) is not.
(*) e.g. with LVM1, when /scratch is to small:
umount /dev/vg00/lv_scratch
e2fsadm.lvm1 -L +5G /dev/vg00/lv_scratch
mount /dev/vg00/lv_scratch
or with LVM2 (we really need to have e2fsadm.lvm2 or better yet a script
that can detect whether t operates on LVM1 or LVM2):
umount /dev/vg00/lv_scratch
lvm lvextend -L +5G /dev/vg00/lv_scratch
resize2fs /dev/vg00/lv_scratch
mount /dev/vg00/lv_scratch
or with FC3 kernels and tools even online:
lvm lvextend -L +5G /dev/vg00/lv_scratch
ext2online /dev/vg00/lv_scratch
(**) e.g. smartd warns you that /dev/sdb which contains the physical
volume /dev/sdb1 is about to fail, so you do simply:
plug in a new disk (say /dev/sdc)
create first partition of type 8e (Linux LVM)
lvm pvcreate /dev/sdc1
lvm vgextend vg00 /dev/sdc1
lvm pvmove /dev/sdb1 /dev/sdc1
This all is simple (albeit not stupid ;-).
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
10:29 a.m.
On Thu, 2004-10-07 at 10:39 +0200, Nils Philippsen wrote:
(**) e.g. smartd warns you that /dev/sdb which contains the physical
volume /dev/sdb1 is about to fail, so you do simply:
This brings up another issue. Does anaconda combine all available
drives? If so, like software raid 0, striping, lvm will increase the
problems of drive failure, because instead of worrying about one drive
failing, now you have to worry about any of them failing.
7157
days inactive
7158
days old
8 comments
7 participants
participants (7)
-
Chris Adams -
David Hollis -
Jeremy Katz -
Nathan Grennan -
Nils Philippsen -
Russell Coker -
Steven Pritchard