Current File : //usr/local/jetapps/usr/share/rear/layout/save/GNU/Linux/220_lvm_layout.sh |
# Save LVM layout
# TODO: What if there are logical volumes on the system but there is no 'lvm' binary?
# Shouldn't then "rear mkrescue" better error out here than to silently skip LVM altogether?
# Cf. "Try hard to care about possible errors" in https://github.com/rear/rear/wiki/Coding-Style
# Think about a minimal system that was set up by a (full featured) installation system
# but tools to set up things were not installed in the (now running) installed system.
# For example 'parted' is usually no longer needed in the installed system.
# Perhaps this cannot happen for LVM so an 'lvm' binary must exist when LVM is used?
has_binary lvm || return 0
Log "Begin saving LVM layout ..."
local header_printed
local pdev vgrp size uuid pvdisplay_exit_code
local extentsize nrextents vgdisplay_exit_code
local already_processed_lvs=()
local lv_layout_supported lvs_fields
local origin lv vg
local layout modules
local thinpool chunksize stripes stripesize segmentsize poolmetadatasize
local kval infokval
local lvs_exit_code
# General explanation why in this script we use pipes of the form
# COMMAND | while read ... do ... done
# instead of how we usually do it via bash process substitution of the form
# while read ... do ... done < <( COMMAND )
# The reason is that in case of process substitution COMMAND seems to be run "very asynchronously"
# where it seems it is not possible (in a simple and clean way) to get the exit status of COMMAND.
# At least not with bash version 3.2.57 on SLES11-SP4 and not with bash version 4.3.42 on SLES12-SP4
# where I <jsmeix@suse.de> get with both bash versions the same "always failed with exit status 127" result:
# # while read line ; do echo $line ; done < <( pstree -Aplau $$ ) ; wait $! && echo OK || echo FAILED with $?
# bash,885
# `-bash,5627
# `-pstree,5628 -Aplau 885
# -bash: wait: pid 5627 is not a child of this shell
# FAILED with 127
# # while read line ; do echo $line ; done < <( echo | grep -Q foo ) ; wait $! && echo OK || echo FAILED with $?
# grep: invalid option -- 'Q'
# -bash: wait: pid 6030 is not a child of this shell
# FAILED with 127
# This looks like a bug in bash at least up to version 4.3.42 because I think
# pstree correctly reports pid 5627 as a child of pid 885 in contrast to what bash reports.
# It seems that works with bash version 4.4.23 on openSUSE Leap 15.0 where I get:
# # while read line ; do echo $line ; done < <( pstree -Aplau $$ ) ; wait $! && echo OK || echo FAILED with $?
# bash,5821
# `-bash,14287
# `-pstree,14288 -Aplau 5821
# OK
# # while read line ; do echo $line ; done < <( echo | grep -Q foo ) ; wait $! && echo OK || echo FAILED with $?
# grep: invalid option -- 'Q'
# FAILED with 2
# Because ReaR must work with bash version 3.x we cannot use 'wait $!' to get
# the exit status of a COMMAND that is run asynchronously via process substitution.
# In contrast for a pipe ${PIPESTATUS[0]} provides the exit status of its first command
# (in contrast to $? that provides the exit status of the last command in a pipe
# unless 'set -o pipefail' is set which lets $? provide the exit status of
# the last command in a pipe that failed - or 0 if none failed - so $? does
# not provide a reliable way to get the exit status of the first command in a pipe).
# The drawback of using a pipe is that the "while read ... do ... done" part
# is run as separated process (in a subshell) so that e.g. one cannot set variables
# in the "while read ... do ... done" part that are meant to be used after the pipe.
# In contrast with the process substitution method the "while read ... do ... done" part
# runs in the current shell (but then COMMAND seems to be somewhat "out of control").
# Begin of group command that appends its stdout to DISKLAYOUT_FILE:
{
# Get physical_device configuration.
# Format: lvmdev <volume_group> <device> [<uuid>] [<size(bytes)>]
header_printed="no"
# Set pvdisplay separator to '|' to prevent issues with a colon in the path under /dev/disk/by-path
# that contains a ':' in the SCSI slot name.
# Example output of "lvm pvdisplay -C --separator '|' --noheadings --nosuffix --units=b -o pv_name,vg_name,pv_size,pv_uuid"
# on a system where LVM is configured to show the /dev/disk/by-path device names instead of the usual
# /dev/sda etc. (by using a setting like
# filter = [ "r|/dev/disk/by-path/.*-usb-|", "a|/dev/disk/by-path/pci-.*-nvme-|", "a|/dev/disk/by-path/pci-.*-scsi-|", "a|/dev/disk/by-path/pci-.*-ata-|", "a|/dev/disk/by-path/pci-.*-sas-|", "a|loop|", "r|.*|" ]
# in /etc/lvm/lvm.conf):
# /dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:1:0-part1|system|107340627968|7wwpcO-KmNN-qsTE-7sp7-JBJS-vBdC-Zyt1W7
# There are two leading blanks in the output (at least on SLES12-SP4 with LVM 2.02.180).
lvm pvdisplay -C --separator '|' --noheadings --nosuffix --units=b -o pv_name,vg_name,pv_size,pv_uuid | while read line ; do
# With the above example pdev=/dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:1:0-part1
# (the "echo $line" makes the leading blanks disappear)
pdev=$( echo $line | cut -d "|" -f "1" )
# Skip lines that are not describing physical devices
# i.e. lines where pdev does not start with a leading / character:
test "${pdev#/}" = "$pdev" && continue
# Output lvmdev header only once to DISKLAYOUT_FILE:
if is_false $header_printed ; then
echo "# Format for LVM PVs"
echo "# lvmdev <volume_group> <device> [<uuid>] [<size(bytes)>]"
header_printed="yes"
fi
# With the above example vgrp=system
vgrp=$( echo $line | cut -d "|" -f "2" )
# With the above example size=107340627968
size=$( echo $line | cut -d "|" -f "3" )
# With the above example uuid=7wwpcO-KmNN-qsTE-7sp7-JBJS-vBdC-Zyt1W7
uuid=$( echo $line | cut -d "|" -f "4" )
# Translate pdev through diskbyid_mappings file:
pdev=$( get_device_mapping $pdev )
# Translate a sysfs name or device name to the name preferred in ReaR:
pdev=$( get_device_name $pdev )
# Output lvmdev entry to DISKLAYOUT_FILE:
# Check that the required positional parameters in the 'lvmdev' line are non-empty
# because an empty positional parameter would result an invalid 'lvmdev' line
# which would cause invalid parameters are 'read' as input during "rear recover"
# cf. "Verifying ... 'lvm...' entries" in layout/save/default/950_verify_disklayout_file.sh
# The variables are not quoted because plain 'test' without argument results non-zero exit code
# and 'test foo bar' fails with "bash: test: foo: unary operator expected"
# so that this also checks that the variables do not contain blanks or more than one word
# because blanks (actually $IFS characters) are used as field separators in disklayout.conf
# which means the positional parameter values must be exactly one non-empty word.
test $pdev || Error "Cannot make 'lvmdev' entry in disklayout.conf (PV device '$pdev' empty or more than one word)"
if ! test $vgrp ; then
# Valid $pdev but invalid $vgrp (empty or more than one word):
# When $vgrp is empty it means it is a PV that is not part of a VG so the PV exists but it is not used.
# PVs that are not part of a VG are documented as comment in disklayout.conf but they are not recreated
# because they were not used on the original system so there is no need to recreate them by "rear recover"
# (the user can manually recreate them later in his recreated system when needed)
# cf. https://github.com/rear/rear/issues/2596
DebugPrint "Skipping PV $pdev that is not part of a valid VG (VG '$vgrp' empty or more than one word)"
echo "# Skipping PV $pdev that is not part of a valid VG (VG '$vgrp' empty or more than one word):"
contains_visible_char "$vgrp" || vgrp='<missing_VG>'
echo "# lvmdev /dev/$vgrp $pdev $uuid $size"
# Continue with the next line in the output of "lvm pvdisplay -C"
continue
fi
# With the above example the output is:
# lvmdev /dev/system /dev/sda1 7wwpcO-KmNN-qsTE-7sp7-JBJS-vBdC-Zyt1W7 41940992
echo "lvmdev /dev/$vgrp $pdev $uuid $size"
done
# Check the exit code of "lvm pvdisplay -C"
# in the "lvm pvdisplay -C ... | while read line ; do ... done" pipe:
pvdisplay_exit_code=${PIPESTATUS[0]}
test $pvdisplay_exit_code -eq 0 || Error "LVM command 'lvm pvdisplay -C ... -o pv_name,vg_name,pv_size,pv_uuid' failed with exit code $pvdisplay_exit_code"
# Get the volume group configuration:
# Format: lvmgrp <volume_group> <extentsize> [<size(extents)>] [<size(bytes)>]
header_printed="no"
# Example output of "lvm vgdisplay -c":
# system:r/w:772:-1:0:2:2:-1:0:1:1:20967424:4096:5119:5117:2:lqIC4T-u5KW-f57o-TpIZ-AYxD-rm3f-06sa6J
# There are two leading blanks in the output (at least on SLES12-SP4 with LVM 2.02.180).
lvm vgdisplay -c | while read line ; do
# With the above example vgrp=system
# (the "echo $line" makes the leading blanks disappear)
vgrp=$( echo $line | cut -d ":" -f "1" )
# With the above example size=20967424
# ( size = 20967424 = 4096 * 5119 = extentsize * nrextents )
size=$( echo $line | cut -d ":" -f "12" )
# With the above example extentsize=4096
extentsize=$( echo $line | cut -d ":" -f "13" )
# With the above example nrextents=5119
nrextents=$( echo $line | cut -d ":" -f "14" )
# Output lvmgrp header only once to DISKLAYOUT_FILE:
if is_false $header_printed ; then
echo "# Format for LVM VGs"
echo "# lvmgrp <volume_group> <extentsize> [<size(extents)>] [<size(bytes)>]"
header_printed="yes"
fi
# Output lvmgrp entry to DISKLAYOUT_FILE:
# With the above example the output is:
# lvmgrp /dev/system 4096 5119 20967424
echo "lvmgrp /dev/$vgrp $extentsize $nrextents $size"
# Check that the required positional parameters in the 'lvmgrp' line are non-empty.
# The tested variables are intentionally not quoted here, cf. the code above to
# "check that the required positional parameters in the 'lvmdev' line are non-empty".
# Two separated simple 'test $vgrp && test $extentsize' commands are used here because
# 'test $vgrp -a $extentsize' does not work when $vgrp is empty or only blanks
# because '-a' has two different meanings: "EXPR1 -a EXPR2" and "-a FILE" (see "help test")
# so with empty $vgrp it becomes 'test -a $extentsize' that tests if a file $extentsize exists
# which is unlikely to be true but it is not impossible that a file $extentsize exists
# so when $vgrp is empty (or blanks) 'test $vgrp -a $extentsize' might falsely succeed:
test $vgrp && test $extentsize || Error "LVM 'lvmgrp' entry in $DISKLAYOUT_FILE where volume_group or extentsize is empty or more than one word"
done
# Check the exit code of "lvm vgdisplay -c"
# in the "lvm vgdisplay -c | while read line ; do ... done" pipe:
vgdisplay_exit_code=${PIPESTATUS[0]}
test $vgdisplay_exit_code -eq 0 || Error "LVM command 'lvm vgdisplay -c' failed with exit code $vgdisplay_exit_code"
# Get all logical volumes:
# Format: lvmvol <volume_group> <name> <size(bytes)> <layout> [key:value ...]
header_printed="no"
already_processed_lvs=()
# Check for 'lvs' support of the 'lv_layout' field:
lvm lvs -o lv_layout &>/dev/null && lv_layout_supported="yes" || lv_layout_supported="no"
# Specify the fields for the lvs command depending on whether or not the 'lv_layout' field is supported:
if is_true $lv_layout_supported ; then
lvs_fields="origin,lv_name,vg_name,lv_size,lv_layout,pool_lv,chunk_size,stripes,stripe_size,seg_size,lv_metadata_size"
else
# Use the 'modules' field as fallback replacement when the 'lv_layout' field is not supported:
lvs_fields="origin,lv_name,vg_name,lv_size,modules,pool_lv,chunk_size,stripes,stripe_size,seg_size,lv_metadata_size"
fi
# Example output of "lvs --separator=':' --noheadings --units b --nosuffix -o $lvs_fields"
# with lvs_fields="origin,lv_name,vg_name,lv_size,lv_layout,pool_lv,chunk_size,stripes,stripe_size,seg_size,lv_metadata_size"
# i.e. when the 'lv_layout' field is supported:
# :home:system:6148849664:linear::0:1:0:6148849664:
# :root:system:14050918400:linear::0:1:0:14050918400:
# :swap:system:1262485504:linear::0:1:0:1262485504:
# There are two leading blanks in the output (at least on SLES12-SP4 with LVM 2.02.180 and SLES15-SP3 with LVM 2.03.05).
# The 'lvs' output lines ordering does not match the ordering of the LVs kernel device nodes /dev/dm-N
# # lsblk -ipbo NAME,KNAME,TYPE,FSTYPE,SIZE,MOUNTPOINT /dev/sda2
# NAME KNAME TYPE FSTYPE SIZE MOUNTPOINT
# /dev/sda2 /dev/sda2 part LVM2_member 21465382400
# |-/dev/mapper/system-swap /dev/dm-0 lvm swap 1262485504 [SWAP]
# |-/dev/mapper/system-root /dev/dm-1 lvm btrfs 14050918400 /
# `-/dev/mapper/system-home /dev/dm-2 lvm xfs 6148849664 /home
# This means during "rear recover" the LVs would get recreated according to the ordering of the 'lvs' output lines
# because during "rear recover" LVs get recreated according to the ordering of the 'lvmvol' lines in disklayout.conf
# so the recreated LVs get different kernel device nodes /dev/dm-N compared to what there was on the original system.
# This did not cause any issue at ReaR so far so it seems safe to assume it does not matter in practice
# what kernel device node /dev/dm-0 /dev/dm-1 /dev/dm-2 belongs to the LVs
# because in practice LVs seem to be always accessed via their symlinks
# /dev/mapper/system-swap /dev/mapper/system-root /dev/mapper/system-home
# cf. https://github.com/rear/rear/pull/2291#issuecomment-567933705
# Therefore we can re-order the 'lvs' output lines as we need it to make "rear recover" behave more fail safe
# when it is run on a bit smaller replacement disk(s) so one or more LVs need to be automatically shrink a bit.
# The automated LVs shrinking is not intended when replacement disk(s) are substantially smaller.
# To migrate onto a substantially smaller replacement disk the user must in advance
# manually adapt his disklayout.conf file before he runs "rear recover".
# The basic idea to automatically shrink LVs is to implement a "minimal changes" approach
# cf. "minimal changes" in layout/prepare/default/420_autoresize_last_partitions.sh
# where the "minimal changes" approach is here to only shrink one single LV per disk if needed.
# A LV needs to shrink only if it is not possible to recreate all LVs with their specified size
# i.e. when during "rear recover" 'lvcreate' fails with "Volume group ... has insufficient free space".
# In this case 'lvcreate' is called again where the exact size option of the form '-L 123456b'
# is replaced with an option to use all remaining free space in the VG via '-l 100%FREE'
# so e.g. 'lvcreate -L 123456b -n LV VG' becomes 'lvcreate -l 100%FREE -n LV VG'
# see layout/prepare/GNU/Linux/110_include_lvm_code.sh
# The most reasonable LVs that can shrink a bit with a "minimal changes" approach are the biggest LVs
# because we assume that the data of the backup can still be restored into a big LV after it was shrunk a bit.
# So we sort the 'lvs' output lines by the size of the LVs (4th field in the output lines, 1st field is two blanks)
# so that the biggest LVs get listed last in disklayout.conf and get recreated last during "rear recover"
# so 'lvcreate' may only fail with "Volume group ... has insufficient free space" for some of the biggest LVs.
# Additionally it had happened during my <jsmeix@suse.de> initial tests that shrinking the 'swap' LV somehow caused
# that the recreated system did not boot (boot screen showed GRUB but there it hung with constant 100% CPU usage)
# so automatically shrinking only the biggest LVs avoids that a relatively small 'swap' LV gets shrunk.
# With 'sort -n -t ':' -k 4' the above 'lvs' output lines become
# :swap:system:1262485504:linear::0:1:0:1262485504:
# :home:system:6148849664:linear::0:1:0:6148849664:
# :root:system:14050918400:linear::0:1:0:14050918400:
# so only the 'root' LV may get automatically shrink if needed.
lvm lvs --separator=':' --noheadings --units b --nosuffix -o $lvs_fields | sort -n -t ':' -k 4 | while read line ; do
# Output lvmvol header only once to DISKLAYOUT_FILE:
if is_false $header_printed ; then
echo "# Format for LVM LVs"
echo "# lvmvol <volume_group> <name> <size(bytes)> <layout> [key:value ...]"
header_printed="yes"
fi
# With the above example origin=""
# (the "echo $line" makes the leading blanks disappear)
origin="$( echo "$line" | awk -F ':' '{ print $1 }' )"
# Skip snapshots (useless) or caches (dont know how to handle that)
if test "$origin" ; then
echo "# Skipped snapshot or cache information '$line'"
continue
fi
# With the above example lv=root and lv=swap
lv="$( echo "$line" | awk -F ':' '{ print $2 }' )"
# With the above example vg=system
vg="$( echo "$line" | awk -F ':' '{ print $3 }' )"
# With the above example size=19927138304 and size=1535115264
size="$( echo "$line" | awk -F ':' '{ print $4 }' )"
if is_true $lv_layout_supported ; then
# With the above example layout=linear
layout="$( echo "$line" | awk -F ':' '{ print $5 }' )"
else
modules="$( echo "$line" | awk -F ':' '{ print $5 }' )"
fi
# With the above example thinpool=""
thinpool="$( echo "$line" | awk -F ':' '{ print $6 }' )"
# With the above example chunksize=0
chunksize="$( echo "$line" | awk -F ':' '{ print $7 }' )"
# With the above example stripes=1
stripes="$( echo "$line" | awk -F ':' '{ print $8 }' )"
# With the above example stripesize=0
stripesize="$( echo "$line" | awk -F ':' '{ print $9 }' )"
# With the above example segmentsize=19927138304 and segmentsize=1535115264
segmentsize="$( echo "$line" | awk -F ':' '{ print $10 }' )"
# With the above example poolmetadatasize=""
poolmetadatasize="$( echo "$line" | awk -F ':' '{ print $11 }' )"
# kval is a string of space-separated key:value pairs. Key names are chosen to represent
# long options to lvcreate, and value will be the parameter for each long option.
# e.g. "chunksize:${chunksize}b" will eventually become a --chunksize=${chunksize}b
# argument to lvcreate.
# This way 110_include_lvm_code.sh which constructs the arguments to lvcreate
# can be kept generic and does not need to be updated every time an argument is added,
# as long as the argument can follow this generic scheme.
# infokval are key:value pairs that are not used when restoring the layout
# and are kept in disklayout.conf only as comments for information
# (because the setting is not easy or desirable to preserve).
kval=""
infokval=""
[ -z "$thinpool" ] || kval="${kval:+$kval }thinpool:$thinpool"
[ -z "$poolmetadatasize" ] || kval="${kval:+$kval }poolmetadatasize:${poolmetadatasize}b"
[ $chunksize -eq 0 ] || kval="${kval:+$kval }chunksize:${chunksize}b"
[ $stripesize -eq 0 ] || kval="${kval:+$kval }stripesize:${stripesize}b"
[ $segmentsize -eq $size ] || infokval="${infokval:+$infokval }segmentsize:${segmentsize}b"
# TODO: Explain what that code is meant to do:
if is_true $lv_layout_supported ; then
# TODO: Explain what that code is meant to do:
if [[ ,$layout, == *,mirror,* ]] ; then
kval="${kval:+$kval }mirrors:$(($stripes - 1))"
elif [[ ,$layout, == *,striped,* ]] ; then
kval="${kval:+$kval }stripes:$stripes"
fi
else
# TODO: Explain what that code is meant to do:
if [[ "$modules" == "" ]] ; then
layout="linear"
[ $stripes -eq 0 ] || kval="${kval:+$kval }stripes:$stripes"
elif [[ ,$modules, == *,mirror,* ]] ; then
layout="mirror"
kval="${kval:+$kval }mirrors:$(($stripes - 1))"
elif [[ ,$modules, == *,thin-pool,* ]] ; then
if [ -z "$thinpool" ] ; then
layout="thin,pool"
else
layout="thin,sparse"
fi
elif [[ ,$modules, == *,raid,* ]] ; then
LogPrintError "LVM: Collecting RAID information for LV '$lv' unsupported ('lv_layout' field not supported). Automatic disk layout recovery may fail."
layout="raid,RAID_UNKNOWNTYPE"
kval="${kval:+$kval }stripes:$stripes"
fi
fi
# Output lvmvol entry to DISKLAYOUT_FILE:
if IsInArray "$vg/$lv" "${already_processed_lvs[@]}" ; then
# The LV has multiple segments.
# The create_lvmvol() function in 110_include_lvm_code.sh is not able to recreate this.
# But we keep the information for the administrator anyway:
echo "#lvmvol /dev/$vg $lv ${size}b $layout $kval"
if [ -n "$infokval" ] ; then
echo "# Extra parameters for the '#lvmvol /dev/$vg $lv' line above not taken into account when restoring using 'lvcreate': $infokval"
fi
else
if [ $segmentsize -ne $size ] ; then
echo "# Volume $vg/$lv has multiple segments. Recreating it by 'lvcreate' will not preserve segments and properties of the other segments as well"
fi
# With the above example the output is:
# lvmvol /dev/system root 19927138304b linear
# lvmvol /dev/system swap 1535115264b linear
echo "lvmvol /dev/$vg $lv ${size}b $layout $kval"
if [ -n "$infokval" ] ; then
echo "# Extra parameters for the 'lvmvol /dev/$vg $lv' line above not taken into account when restoring using 'lvcreate': $infokval"
fi
already_processed_lvs+=( "$vg/$lv" )
# Check that the required positional parameters in the 'lvmvol' line are non-empty
# cf. the code above to "check that the required positional parameters in the 'lvmdev' line are non-empty"
# and the code above to "check that the required positional parameters in the 'lvmgrp' line are non-empty":
test $vg && test $lv && test $size && test $layout || Error "LVM 'lvmvol' entry in $DISKLAYOUT_FILE where volume_group or name or size or layout is empty or more than one word"
fi
done
# Check the exit code of "lvm lvs --separator=':' --noheadings --units b --nosuffix -o $lvs_fields"
# in the "lvm lvs --separator=':' --noheadings --units b --nosuffix -o $lvs_fields | while read line ; do ... done" pipe:
lvs_exit_code=${PIPESTATUS[0]}
test $lvs_exit_code -eq 0 || Error "LVM command 'lvs ... -o $lvs_fields' failed with exit code $lvs_exit_code"
} 1>>$DISKLAYOUT_FILE
# End of group command that appends its stdout to DISKLAYOUT_FILE
Log "End saving LVM layout"
# 'lvm' is required in the recovery system if disklayout.conf contains at least one 'lvmdev' or 'lvmgrp' or 'lvmvol' entry
# see the create_lvmdev create_lvmgrp create_lvmvol functions in layout/prepare/GNU/Linux/110_include_lvm_code.sh
# what program calls are written to diskrestore.sh
# cf. https://github.com/rear/rear/issues/1963
grep -Eq '^lvmdev |^lvmgrp |^lvmvol ' $DISKLAYOUT_FILE && REQUIRED_PROGS+=( lvm ) || true
# vim: set et ts=4 sw=4: