f764e5b520
With 4k disks, it appears that we can encounter cases where logical block sizes being larger begins to chip away at space at the beginning *and* end of an LVM Physical Volume (PV). With GPT, a similar issue occurs, larger logical block sizes increases the number of bytes used at the beginning and end of disk for metadata storage. For the PV, the signature is on the second logical block, and there is also reference to a potential backup at the end of the volume. Which means the overall available space goes from just being impacted by 1kB to at least 8kB. This can then begin to impact overall alignment which is in 4MB blocks on top of the base device. The attempt here is to dial the sizing back just a little bit, so we avoid assumptions regarding volume sizing ever possibly conflicting or cases where we somehow end up asking to grow a volume on a physical volume group which exceeds the number of extents LVM has calculated. Example failure this intends to avoid similar errors on a 4k disk when growvols is triggered: Exception: Running command failed: cmd "lvextend -L+952065064960B /dev/mapper/vg-lv_thinpool /dev/sdc6" Which involves Standard Error ouptut along the lines of: "Insufficient free space: 226990 extents needed, but only 226988 available" With this change, we will apply logic to *both* the extent size of the thinpool, if any, and all logical volumes which effectively reduces the leveraged volumes by 8MB or two LVM extents, because growvols tries to convert the user's preference of size or percentage to bytes, which doesn't compensate for the additional lost extents on a 4k block device. Change-Id: I303d504f3c822fd534f3e3642d85873ba30d3f68 |
||
---|---|---|
.. | ||
environment.d | ||
init-scripts/systemd | ||
post-install.d | ||
static/usr/local/sbin | ||
tests | ||
__init__.py | ||
element-deps | ||
package-installs.yaml | ||
README.rst |
growvols
Grow one or more LVM volumes on first boot.
This installs utility growvols which grows the logical volumes in an LVM group to take available device space.
The positional arguments specify how available space is allocated. They have the format <volume>=<amount><unit> where:
<volume> is the label or the mountpoint of the logical volume <amount> is an integer growth amount in the specified unit <unit> is one of the supported units
Supported units are:
% percentage of available device space before any changes are made MiB mebibyte (1048576 bytes) GiB gibibyte (1073741824 bytes) MB megabyte (1000000 bytes) GB gigabyte (1000000000 bytes)
Each argument is processed in order and the requested amount is allocated to each volume until the disk is full. This means that if space is overallocated, the last volumes may only grow by the remaining space, or not grow at all, and a warning will be printed. When space is underallocated the remaining space will be given to the root volume (mounted at /).
The currently supported partition layout is: - Exactly one of the partitions containing an LVM group - The disk having unpartitioned space to grow with - The LVM logical volumes being formatted with XFS filesystems
Example usage:
growvols /var=80% /home=20GB
growvols --device sda --group vg img-rootfs=20% fs_home=20GiB fs_var=60%
Environment variables can be set during image build to enable a systemd unit which will run growvols on boot:
# DIB_GROWVOLS_TRIGGER defaults to 'manual'. When set to 'systemd' a systemd # unit will run using the following arguments export DIB_GROWVOLS_TRIGGER=systemd
# DIB_GROWVOLS_ARGS contains the positional arguments for which volumes to grow # by what amount. If omitted the volume mounted at / will grow by all available # space export DIB_GROWVOLS_ARGS="img-rootfs=20% fs_home=20GiB fs_var=60%"
# DIB_GROWVOLS_GROUP contains the name of the LVM group to extend. Defaults the # discovered group if only one exists. export DIB_GROWVOLS_GROUP=vg
# DIB_GROWVOLS_DEVICE is the name of the disk block device to grow the # volumes in (such as "sda"). Defaults to the disk containing the root mount. export DIB_GROWVOLS_DEVICE=sda