LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (http://www.linuxquestions.org/questions/linux-software-2/)
-   -   A pretty basic LVM question (http://www.linuxquestions.org/questions/linux-software-2/a-pretty-basic-lvm-question-4175422194/)

killy9999 08-15-2012 09:20 AM

A pretty basic LVM question
 
Hi guys,

I have a laptop with one hard drive partitioned into many volumes: /, /home, swap and /data. I'm facing a common problem of guessing how big the partitions should be and then hoping I'm right. I'd like to have an option of resizing my partitions easily and thought that LVM might be a good solution. I found some tutorials, but still there are some pretty basic concepts I don't understand:

1. Let's say I have one logical group on one hard drive and many logical volumes within that group. What happens if I physically switch that drive to a different computer? Will the LVM volumes be recognized and placed in /dev? Does kernel require additional modules to handle LVM (I suppose it does)? What about grub? In general, how different is handling of LVM volumes from physical partitions?

2. Does LVM hinder performance?

3. Does LVM increase risk of losing data in any way?

thebombzen 08-15-2012 11:39 AM

Quote:

Originally Posted by killy9999 (Post 4754697)
Hi guys,
1. Let's say I have one logical group on one hard drive and many logical volumes within that group. What happens if I physically switch that drive to a different computer? Will the LVM volumes be recognized and placed in /dev?

The data that holds the information about the volume group (it's called a volume group, not a logical group) has to be stored somewhere. If you have only one hard drive, that's where it's going to be. Transplanting all the drives that contain physical volumes in a volume group should completely transplant a volume group.

Quote:

Originally Posted by killy9999 (Post 4754697)
Does kernel require additional modules to handle LVM (I suppose it does)? What about grub? In general, how different is handling of LVM volumes from physical partitions?

I think the Linux Kernel usually comes with the LVM modules on any modern system (even Arch Linux). Also, Linux does not boot off of LVM, it boots off of an ext4 boot partition (/boot). Grub doesn't understand LVM, but it doesn't need to.

Quote:

Originally Posted by killy9999 (Post 4754697)
2. Does LVM hinder performance?

It should only hinder performance if you are writing a file and the file has to switch from writing contiguously to somewhere else (because the current amount of space ran out). However this should happen infrequently because you still have many GiB (tens or hundreds, depending on drive size) of contiguous space, and Linux won't leave fragments lying around the way Windows does. Therefore, File I/O will still be just as fast, and still be faster than on Windows :D

Quote:

Originally Posted by killy9999 (Post 4754697)
3. Does LVM increase risk of losing data in any way?

It does have this risk if you are using multiple hard drives without backups, because generally if one hard drive containing a physical volume crashes and is unusable, then any logical volume that uses space on that physical volume will also not work. However, with only one hard drive, the only issues you would run into would be that one drive crashing, which is just as likely with or without LVM, and would have equal consequences. So, with one hard drive, the answer to 3. is NO, but with two hard drives it's twice as likely, three would be three times, etc.

syg00 08-16-2012 03:56 AM

Things change all the time.
Grub2 can boot from a lv - a separate (non-LVM) /boot partition may still be preferable, but is no longer actually a requirement.

Being an extra layer of software, LVM might have the potential to "hinder performance". I defy you to be able to measure the difference, if any.

LVM2 is the preferred arrangement for Enterprise environments - I think you can be confident your data is no less safe by using it.

killy9999 08-16-2012 09:05 AM

Thanks for explanations! I just installed Debain Wheezy on a virtual machine and played with LVM a little bit. It certainly does not require separate /boot partition. syg00, why do you say it might be preferable to have a separate partition for boot?

subvertigo 08-16-2012 10:26 AM

I imagine you want a separate /boot partition because it's not something you'd want to lose. When I ran the phoronix test suite's disk benchmark with LVM+ext4 vs straight ext4, the performance loss (if any) wasn't noticeable. Disks are just too slow.

The lvm2 suite and programs like vg_scan, vgchange -ay, and devices that show up in /dev/mapper are the 'new' things you'll see.

If you have a volume group on your laptop, the partition type will be 8e (Linux LVM) instead of 83 (Linux). This will help vg_scan find the partition. Moving the disk to a different computer or booting a different Linux distro won't change the partition type.

Ultimately, even with LVM you'll have to resize the data area with resize2fs, and then resize the logical volume with lvchange. The advantage of not being stuck with continuous partitions (you can shrink the /home logical volume and use the free extents with the /data logical volume, even with the swap logical volume in between) looks like what you want.

killy9999 08-16-2012 10:34 AM

Quote:

Originally Posted by subvertigo (Post 4755701)
I imagine you want a separate /boot partition because it's not something you'd want to lose.

I'm missing something here. Sure I wouldn't want to lose /boot, but I wouldn't want to lose /, /home or /data.

subvertigo 08-16-2012 10:43 AM

What I meant by 'losing' it is that when things move around on the volume group they may move outside the range of the BIOS. I couldn't find any information saying that GRUB2 uses it's own disk driver, so I'm assuming that if it's outside of what the BIOS can address, it can't be loaded into memory.

If you encrypt your LVM partition, GRUB2 will also be unable to find /boot.

killy9999 08-16-2012 11:12 AM

Now this makes sense. Thanks.


All times are GMT -5. The time now is 12:27 PM.