----- Original Message -----
|
| 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.
There are no partitions, so partition alignment is moot. That doesn't mean that you don't need to also align the file system layout, but at least you don't have to account for both partition alignment *and* file system alignment.
BTW: XFS detects this automatically if it can talk directly to the hardware otherwise you need to specify the sw= and su= values accordingly.
--
James A. Peltier
Manager, IT Services - Research Computing Group
Simon Fraser University - Burnaby Campus
Phone : 778-782-6573
Fax : 778-782-3045
E-Mail : jpeltier@xxxxxx
Website : http://www.sfu.ca/itservices
“A successful person is one who can lay a solid foundation from the bricks others have thrown at them.” -David Brinkley via Luke Shaw
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
