On 09/26/2013 09:35 PM, James A. Peltier wrote: > ----- Original Message ----- > | ----- Original Message ----- > | | Hi, > | | > | | I was wondering, why/when it is useful or when should I avoid to > | | use > | | LVM. > | | > | | I think the big advantage of LVMing is if you modify (rezising, > | | ...) > | | disk and filesystem layouts "a lot". > | | > | | Are there any real pros or cons for following situations regarding > | | e.g. > | | management and speed? > | > | The speed at which you can manage your disk environment through the > | use of LVM makes most of the tradeoffs worth while. Of course, YMMV > | so you're best to test. > | > | | e.g.: > | | > | | I do have a server system raid for which the disk layout will not > | | change; e.g. /var /usr /home will not change much in size. > | > | This isn't so much the issue. What if *any* partition requirements > | *do* change in the future. LVM can account for that my allowing you > | flexibility to make a change should it be required. Standard > | partitioning is less flexible in this regard. > | > | | OR > | | > | | I do have some file storage shares (iscsi raids) up to some TB each > | | on > | | one big storage device. > | | > | | Sometimes (e.g. after a server crash) it is useful to remount the > | | storage to a different server. > | > | Standard caveats apply. If the Volume Groups or the Logical Volumes > | are named the same moving them to another system with similar VGs or > | LVs can be problematic. Same goes for file system labels, albeit > | both are relatively easy to fix in such a scenario. > | > | | Should I use LVM on the iscsi storage volumes? > | > | I would find it difficult to find a case where LVM shouldn't be used > | because of it's flexibility. I tend to use full disk LVM (no > | partitions at all) and file system labels for mounting and the like > | (labels match LVs). > | > | lvcreate -L 20G -n csgrad DATA > | mkfs.xfs -L csgrad /dev/DATA/csgrad > | > | /etc/fstab > | ---------- > | > | LABEL=csgrad /exports/csgrad xfs defaults 0 0 > | > | > | LVM offers other additional flexibility too in that you can migrate > | PVs from one device to another online. So if you have one iSCSI > | server that is coming off support and you are replacing it with > | another, you can use pvmove to move the data from one target to > | another. > > Oh! One last case in point. Partition Alignment. This is very important to the performance of a disk subsystem. With full disk LVM it's not an issue at all. > Not having much experience with LVM, I just wondered how this last comment applies. Surely the alignment of partitions has got to do with the underlying hardware and how it seeks to and finds the beginning of where it wants to read - the sector. I am curious how LVM negates this hardware constraint.