brw-rw---- 1 root disk 253, 2 5 oct. 18:14 /dev/dm-2
NOTE Autodetecting LVM volumes
When the computer boots, the /etc/init.d/lvm script scans the available devices; those that have been initialised as physical volumes for LVM are registered into the LVM subsystem, those that belong to volume groups are assembled, and the relevant logical volumes are started and made available. There is therefore no need to edit configuration files when creating or modifying LVM volumes.
Note, however, that the layout of the LVM elements (physical and logical volumes, and volume groups) is backed up in /etc/lvm/backup, which can be useful in case of a problem (or just to sneak a peek under the hood).
To make things easier, convenience symbolic links are also created in directories matching the VGs:
# ls -l /dev/vg_critical
total 0
lrwxrwxrwx 1 root root 7 5 oct. 18:14 lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 5 oct. 18:14 lv_files -> ../dm-0
# ls -l /dev/vg_normal
total 0
lrwxrwxrwx 1 root root 7 5 oct. 18:14 lv_backups -> ../dm-2
The LVs can then be used exactly like standard partitions:
# mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
[...]
This filesystem will be automatically checked every 34 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
# mkdir /srv/backups
# mount /dev/vg_normal/lv_backups /srv/backups
# df -h /srv/backups
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_normal-lv_backups
12G 159M 12G 2% /srv/backups
# [...]
[...]
# cat /etc/fstab
[...]
/dev/vg_critical/lv_base /srv/base ext4
/dev/vg_critical/lv_files /srv/files ext4
/dev/vg_normal/lv_backups /srv/backups ext4
From the applications' point of view, the myriad small partitions have now been abstracted into one large 12 GB volume, with a friendlier name.
12.1.2.3. LVM Over Time
Even though the ability to aggregate partitions or physical disks is convenient, this is not the main advantage brought by LVM. The flexibility it brings is especially noticed as time passes, when needs evolve. In our example, let's assume that new large files must be stored, and that the LV dedicated to the file server is too small to contain them. Since we haven't used the whole space available in vg_critical, we can grow lv_files. For that purpose, we'll use the lvresize command, then resize2fs to adapt the filesystem accordingly:
# df -h /srv/files/
Filesystem Size Used Avail Use% Mounted on/dev/mapper/vg_critical-lv_files 5.0G 4.6G 142M 98% /srv/files
# lvdisplay -C vg_critical/lv_files
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
lv_files vg_critical -wi-ao 5.00g
# vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree
vg_critical 2 2 0 wz--n- 8.14g 2.14g
# lvresize -L 7G vg_critical/lv_files
Extending logical volume lv_files to 7.00 GB
Logical volume lv_files successfully resized
# lvdisplay -C vg_critical/lv_files
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
lv_files vg_critique -wi-ao 7.00g
# resize2fs /dev/vg_critical/lv_files
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/vg_critical/lv_files to 1835008 (4k) blocks.
The filesystem on /dev/vg_critical/lv_files is now 1835008 blocks long.
# df -h /srv/files/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files
6.9G 4.6G 2.1G 70% /srv/files
CAUTION Resizing filesystems
Not all filesystems can be resized online; resizing a volume can therefore require unmounting the filesystem first and remounting it afterwards. Of course, if one wants to shrink the space allocated to an LV, the filesystem must be shrunk first; the order is reversed when the resizing goes in the other direction: the logical volume must be grown before the filesystem on it. It's rather straightforward, since at no time must the filesystem size be larger than the block device where it resides (whether that device is a physical partition or a logical volume).
The ext3, ext4 and xfs filesystems can be grown online, without unmounting; shrinking requires an unmount. The reiserfs filesystem allows online resizing in both directions. The venerable ext2 allows neither, and always requires unmounting.
We could proceed in a similar fashion to extend the volume hosting the database, only we've reached the VG's available space limit:
# df -h /srv/base/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base
1008M 835M 123M 88% /srv/base
# vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree
vg_critical 2 2 0 wz--n- 8.14g 144.00m
No matter, since LVM allows adding physical volumes to existing volume groups. For instance, maybe we've noticed that the sdb1 partition, which was so far used outside of LVM, only contained archives that could be moved to lv_backups. We can now recycle it and integrate it to the volume group, and thereby reclaim some available space. This is the purpose of the vgextend command. Of course, the partition must be prepared as a physical volume beforehand. Once the VG has been extended, we can use similar commands as previously to grow the logical volume then the filesystem:
# pvcreate /dev/sdb1
Physical volume "/dev/sdb1" successfully created
# vgextend vg_critical /dev/sdb1
Volume group "vg_critical" successfully extended
# vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree
vg_critical 3 2 0 wz--n- 9.09g 1.09g