In various places kdump-utils requires information about the dump target, e.g. the fs type, mount point, persistent device etc.. Currently these information are not stored anywhere but every place that requires them have to call the same functions over and over again. This is not only confusing but also leads to inconsistencies when the same information is retrieved on a (slightly) different way in different places. Furthermore, this behavior contributes to the problem described in #139 where kdump.conf gets parsed over and over again. For example take kdumpctl:check_fs_modified. The start of the function looks like this
check_fs_modified()
{
local _old_dev _old_mntpoint _old_fstype
local _new_dev _new_mntpoint _new_fstype
local _target _dracut_args
# No need to check in case of mount target specified via "dracut_args".
if is_mount_in_dracut_args; then
return 0
fi
# No need to check in case of raw target.
# Currently we do not check also if ssh/nfs/virtiofs/thinp target is specified
if is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target ||
is_virtiofs_dump_target || is_lvm2_thinp_dump_target; then
return 0
fi
_target=$(get_block_dump_target)
[...]
Each of the functions called in the code snippet above parses kdump.conf at least once. Some parse it multiple times, e.g. get_block_dump_target parses it up to 4(!) times. What makes it even worse is that is_lvm2_thinp_dump_target as well as check_drivers_modified (the function called right after check_fs_modified) also call get_block_dump_target. This means that the same function is called three times in quick succession to fetch the same information causing kdump.conf to be parsed up to 12 times.
Fix this by fetching and storing the required information once when kdumpctl starts so that it can be re-used later on.
In various places
kdump-utilsrequires information about the dump target, e.g. the fs type, mount point, persistent device etc.. Currently these information are not stored anywhere but every place that requires them have to call the same functions over and over again. This is not only confusing but also leads to inconsistencies when the same information is retrieved on a (slightly) different way in different places. Furthermore, this behavior contributes to the problem described in #139 wherekdump.confgets parsed over and over again. For example takekdumpctl:check_fs_modified. The start of the function looks like thisEach of the functions called in the code snippet above parses
kdump.confat least once. Some parse it multiple times, e.g.get_block_dump_targetparses it up to 4(!) times. What makes it even worse is thatis_lvm2_thinp_dump_targetas well ascheck_drivers_modified(the function called right aftercheck_fs_modified) also callget_block_dump_target. This means that the same function is called three times in quick succession to fetch the same information causingkdump.confto be parsed up to 12 times.Fix this by fetching and storing the required information once when
kdumpctlstarts so that it can be re-used later on.