On Sat, 2011-04-02 at 19:42 -0400, Kyle Gonzales wrote: > > And yet, there are hundreds of thousands, perhaps millions of installs > using LVM without issue.
Yes, but I doubt they all have / running on a lvm partition/volume :) > > 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. Never said you were incorrect ;) > 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? Complex is in the eye of the beholder. Again its not complex at all. I have no idea why you assume it to be such. However when it comes to being able to recover a system, I rather haven taken a more complex route that I know will not bite me in the butt later :) > 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. Your talking VM, what about the host machine? Dealing with VMs is trivial to dealing with the host machine ;) What about the link I provided to Gentoo or Wikipedia has anything to do with MY way? Clearly not the entire world feels as RH does by having RHEL default to putting / on a lvm partition. > >> 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. You said all partitions, and then quoted save /boot till grub2. RHEL does not ship with grub2. Either way /boot being on lvm is covered by your statement to use LVM for all partitions. > /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. Again thats valid in your opinion and that of RedHat. Clearly the rest of the world does not feel the same. Per the documents I provided links to, which I had no involvement with. > > 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. Again I said it was a valid use case. Just the same you could use Linux software raid on top of two raid arrays. :) > >> * 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. Again if no files on / have changed, what savings is there in the snapshot size? > 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. pvmove does not work across volume groups, only with disks within the volume group your working with. Also have you never seen a warning such as pvmove -- moving physical extents in active volume group "dev" pvmove -- WARNING: moving of active logical volumes may cause data loss! pvmove -- do you want to continue? [y/n] y > >> * 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. That has been the Unix way for decades. > Many people need to resize or change their partitions. I am talking only about /. There is need at times to change partition sizes of most any other. You are all over the place here. > 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. LVM is very wasteful and fragments and can cause degradation of performance for underlying raid arrays. Once again "Logical volumes can suffer from external fragmentation when the underlying storage devices do not allocate their PEs contiguously. This can reduce I/O performance on slow-seeking media (such as magnetic disks), which have to seek over the gaps between extents during large sequential reads or writes. Volume managers which use fixed-size PEs, however, typically make PEs relatively large (a default of 4MB on the Linux LVM, for example) in order to amortize the cost of these seeks." http://en.wikipedia.org/wiki/Logical_volume_management#Disadvantages > >> 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). Again, the kernel feature of encrypting either entire file systems or files, is NOT dependent on LVM. You can contest that all you like, but you can build a kernel with all file systems encrypted, that is not using LVM. That is a fact. > 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. That is a point you did not make earlier, and makes your case much stronger. However, you going back to talking about having may partitions again. Something you were calling legacy above? However you do realize dm-crypt can encrypt an entire disk, not just partitions or a single file system. Which can be done without using LVM just the same. :) Here is a how to example, that does NOT use LVM http://www.hermann-uwe.de/blog/howto-disk-encryption-with-dm-crypt-luks-and-debian > >> 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. Then that is very far off, and you can't make a statement that LVM should be used for all partitions. You could you say all but /boot, or most partitions :) -- William L. Thomson Jr. Obsidian-Studios, Inc. http://www.obsidian-studios.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]
