William L. Thomson Jr. wrote: > Let me start with this > > "The levels of indirection that volume managers introduce can complicate > the boot process and make disaster recovery difficult, especially when > the base operating-system and other essential tools are themselves on an > LV." > http://en.wikipedia.org/wiki/Logical_volume_management#Disadvantages
And yet, there are hundreds of thousands, perhaps millions of installs using LVM without issue. > On Sat, 2011-04-02 at 17:07 -0400, Kyle Gonzales wrote: >> Most enterprise class hardware is sourced from Dell, HP, IBM or Sun. > > There are others as well, that make very large systems, Cray, SGI, etc. Yes, of course there are so many others that must be mentioned. And yet, my statement is still correct. >> A feature that all of these cards share is the ability to boot from >> remote media, some even have the ability to store a boot or rescue disk. >> These cards are the "remote hands" for the enterprise IT admin. >> >> When it is necessary to use this feature, it is rarely because someone >> munged an LVM configuration file. So yes, your solution is valid if the >> only concern someone has is that they messed up LVM. That is a very >> narrow use case. > > There could be many others reasons or causes of failures. But the point > remains if you can avoid using a rescue disk, in any form. That usually > will save you time in recovery. Since no matter what form of rescue you > use to boot, you will manually be mounting / and performing other > operations manually. Rescue media just ads more steps. If you have to > use it then you do. But if you can avoid it, it will save steps and > time. Perhaps. But your issue doesn't actually help with many of those "reasons or causes of failures" other than protecting you from LVM. So what is the point of the complex way in which you are doing things? >> If you are breaking out many partitions from /, then perhaps you are >> fortunate enough to have a small root partition. I will still maintain >> that it introduces needless complexity for the problem you are trying to >> solve. > > Unless the entire system is very small like VMs, which consist of a > single partition. Any host machine, will usually have a very small root > partition. With other things broken out onto their own, and typically > being LVMs. Actually, the most useful case I had for LVM was a customer using RHEL in a VM. Customer needed to switch the underlying storage that the VM was running. Because they used LVM in their install, we were able to use pvmove to migrate the VMs storage from one physical volume to another while the VM was running. So, again, your use case seems to indicate the way YOU run things. >>> Thus there is no benefit to having partitions on lvm that do not change >>> in size and may never. Just becomes a potential liability and requires >>> the system to need things like a rescue disk to recover the system. Not >>> to mention some to supply that rescue disk. Unless you leave one in >>> every machine :P >> I am sorry, William, but this is completely and totally false. There >> are many reason to use LVM for all your partitions (save /boot, until >> GRUB2 becomes more commonly used). > > You just contradicted yourself in that same statement. I am only talking > about using it for two partitions, and till your using grub2. You still > have to have a non LVM /boot partition. So your saving the creation of > one partition. Not seeing why that is such a big deal, one vs two. No, I did not. I was pretty clear. You might not want me to be right... but that is a different story. /boot as a raw FS is due to a limitation of GRUB1, which people can get around. Otherwise, managing all other partitions including swap via LVM is valid. Even if your only non-boot partitions are / and swap, its valid. >> Here are just a few use cases from >> Wikipedia: http://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux) >> >> * Managing large hard disk farms by letting you add disks, replace >> disks, copy and share contents from one disk to another without >> disrupting service. > > I could see this one as being a valid use case, replacing the disk / is > on. Though if thats a raided partition to begin with. Which is normally > the case for any enterprise storage hardware, or even non-enterprise > storage. Then there is no benefit. I can go replace disks now, and I > don't need LVM at all :) Sorry, that is incorrect. If you need to migrate the OS from one RAID set to another, LVM is of great benefit. >> * Making backups by taking "snapshots." > > What is the difference between a snapshot and making a tarball of /? If > its contents are not changing, there is no difference. Which / contents > rarely change if other things are on their own partition. > > Sure you can turn around and mount a snapshot and do stuff with that. > But you can do the same by unpacking the tarball on a temporary lvm. Its > not like you can switch the partition / is on with a live system. Go > from one lvm / to a snapshot and the back. Because the snapshot is virtual, only tracking files that have changed. Saves a great deal of space versus copying all the files elsewhere. Some people keep snapshots of daily and weekly. And actually, using LVM, you CAN switch the underlying disk or partition that / is on while a live system is running. I've done it numerous times. pvmove is your friend. >> * Creating single logical volumes of multiple physical volumes or entire >> hard disks (somewhat similar to RAID 0, but more similar to JBOD), >> allowing for dynamic volume resizing. > > Again who is going to resize /? If everything else is on its own > partition? Its been a long time Unix rule of thumb to put things on > their own partition for many reasons. That does not go out the window > when it comes to LVM. Now I guess you could combined two raided devices > into a singe LVM. But thats pretty excessive for /. IF everything is on one partition, indeed. You assume that the only correct way is to fragment the various directories onto multiple partitions. Many people need to resize or change their partitions. If you want to stick to the legacy (and often confusing and wasteful) practice of fracturing your directories into different partitions, be my guest. There are many reasons to highly fracture your file system into various partitions on a single storage device. Unfortunately most of them are for pure legacy that no one has a good reason for. >> An additional recent use case for LVM is whole disk encryption using >> dm-crypt: http://en.wikipedia.org/wiki/Dm-crypt > > That does not depend on lvm. You can use dm-crypt even if your not using > LVM. No case point is being made there. There certainly is for those who want to encrypt the physical volume outside of the individual filesystems. Otherwise you are not able to encrypt the entire disk (sans /boot, which might reside off the disk and does in highly secure mobile use cases). Without LVM, you need to have a single partition that you encrypt to achieve whole disk encryption (basically, everything on /). OR you have to encrypt every single file system partition you want encrypted separately. Using LVM, you create a single physical volume that is encrypted. Once unlocked, the system will scan the volume for volume groups and logical volumes. >> The only current caveat is the inability for GRUB1 to boot from LVM, >> requiring /boot to not be hosted on LVM. GRUB2 removes this limitation. > > When will RHEL ship with Grub2? Very few distros are shipping that now, > and that includes Gentoo. However some are using grub2 already. Not earlier than RHEL7. Fedora would need to introduce it first. -- Kyle Gonzales [email protected] GPG Key #0x566B435B Read My Tech Blog: http://techiebloggiethingie.blogspot.com/ --------------------------------------------------------------------- Archive http://marc.info/?l=jaxlug-list&r=1&w=2 RSS Feed http://www.mail-archive.com/[email protected]/maillist.xml Unsubscribe [email protected]
