These utility function will be shared by several files, they are all operation related to mount stuff.
Meantime define DEFAULT_PATH="/var/crash".
Signed-off-by: Baoquan He bhe@redhat.com Acked-by: Vivek Goyal vgoyal@redhat.com --- kdump-lib.sh | 21 +++++++++++++++++++++ mkdumprd | 2 +- 2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index de32650..bf57a91 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -3,6 +3,7 @@ # Kdump common variables and functions #
+DEFAULT_PATH="/var/crash/" FENCE_KDUMP_CONFIG="/etc/sysconfig/fence_kdump" FENCE_KDUMP_SEND="/usr/libexec/fence_kdump_send" FENCE_KDUMP_NODES="/etc/fence_kdump_nodes" @@ -75,3 +76,23 @@ get_root_fs_device() return }
+get_mntpoint_from_path() +{ + echo $(df $1 | tail -1 | awk '{print $NF}') +} + +get_target_from_path() +{ + echo $(df $1 | tail -1 | awk '{print $1}') +} + +get_fs_type_from_target() +{ + echo $(findmnt -k -f -n -r -o FSTYPE $1) +} + +get_mntpoint_from_target() +{ + echo $(findmnt -k -f -n -r -o TARGET $1) +} + diff --git a/mkdumprd b/mkdumprd index 84f1e18..3849866 100644 --- a/mkdumprd +++ b/mkdumprd @@ -12,7 +12,7 @@ export IN_KDUMP=1 conf_file="/etc/kdump.conf" SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa" SAVE_PATH=$(grep ^path $conf_file| cut -d' ' -f2) -[ -z "$SAVE_PATH" ] && SAVE_PATH="/var/crash" +[ -z "$SAVE_PATH" ] && SAVE_PATH=$DEFAULT_PATH extra_modules="" dracut_args=("--hostonly" "-o" "plymouth dash resume") OVERRIDE_RESETTABLE=0
kdump need create the dir specified in "path" formerly if it does not exist. Now change the behavior to be that ueser takes charge of the "path", make sure "path" has been created, especially when separate disk is mounted on this "path".
Also introduce 2 helper functions to help check the existence of path.
Signed-off-by: Baoquan He bhe@redhat.com --- kdump-lib.sh | 26 ++++++++++++++++++++++++++ mkdumprd | 33 +-------------------------------- 2 files changed, 27 insertions(+), 32 deletions(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index bf57a91..cf2474a 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -96,3 +96,29 @@ get_mntpoint_from_target() echo $(findmnt -k -f -n -r -o TARGET $1) }
+#This function compose a absolute path with the mount +#point and the relative $SAVE_PATH. +#target is passed in as argument, could be UUID, LABEL, +#block device or even nfs server export of the form of +#"my.server.com:/tmp/export"? +#And possibly this could be used for both default case +#as well as when dump taret is specified. When dump +#target is not specified, then $target would be null. +make_absolute_save_path() +{ + local _target=$1 + local _mnt + + [ -n $_target ] && _mnt=$(get_mntpoint_from_target $1) + echo "${_mnt}/$SAVE_PATH" +} + +check_save_path_fs() +{ + local _path=$1 + + if [ ! -d $_path ]; then + perror_exit "Dump path $_path does not exist." + fi +} + diff --git a/mkdumprd b/mkdumprd index 3849866..adf9167 100644 --- a/mkdumprd +++ b/mkdumprd @@ -173,37 +173,6 @@ mkdir_save_path_ssh() return 0 }
- -#mkdir if save path does not exist on dump target filesystem -#$1=dump target -#caller should ensure $1 is mounted -mkdir_save_path_fs() { - local _mnt=$(to_mount_point $1) - local _remount="no" - local _ret - - [ ! -d ${_mnt}/$SAVE_PATH ] && { - if is_readonly_mount $1; then - echo "Mounting $1 as read-write for creating dump directory.." - mount -o remount,rw $1 || { - perror_exit "Mounting $1 as read-write failed." - } - _remount="yes" - fi - mkdir -p ${_mnt}/$SAVE_PATH - _ret=$? - [ "$_remount" = "yes" ] && { - echo "Remounting $1 as read-only." - mount -o remount,ro $1 || { - perror_exit "Remounting $1 as read-only failed." - } - } - [ $_ret -ne 0 ] && { - perror_exit "Creating ${_mnt}/$SAVE_PATH failed." - } - } -} - #Function: get_fs_size #$1=dump target get_fs_size() { @@ -538,7 +507,7 @@ do add_dracut_module "nfs" fi add_mount "$config_val" - mkdir_save_path_fs $config_val + check_save_path_fs $(make_absolute_save_path $config_val) check_size fs $config_val ;; raw)
When user does not specify dump target explicitly, it's better to dump to the "path" specified. That means after dump user enter into 1st kernel, can find vmcore in the "path". If that path is in root fs, vmcore is stored in root fs. If separate disk is mounted on any tier of "path", we just dump vmcore into the left path on the left separate disk.
E.g in kdump.conf path /mnt/nfs
in mount info, /dev/vdb on /mnt type ext4 (rw,relatime,seclabel,data=ordered)
Then vmcore will be saved in /nfs of /dev/vdb.
In this patch, pass mount info to dracut in this case if separate disk is mounted on any tier of "path".
Meanwhile introduce a function in kdump-lib.sh to check if any target is specified.
v4->v5: Per Vivek's comment, add a helper function is_fs_dump_target. Then is_user_configured_dump_target is rewrite with these helper functions.
Signed-off-by: Baoquan He bhe@redhat.com --- kdump-lib.sh | 24 ++++++++++-------------- mkdumprd | 31 ++++++++++++++++++------------- 2 files changed, 28 insertions(+), 27 deletions(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index cf2474a..5ba6135 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -23,6 +23,16 @@ is_raw_dump_target() grep -q "^raw" /etc/kdump.conf }
+is_fs_dump_target() +{ + egrep -q "^ext[234]|^xfs|^btrfs|^minix" /etc/kdump.conf +} + +is_user_configured_dump_target() +{ + return $(is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target || is_fs_dump_target) +} + strip_comments() { echo $@ | sed -e 's/(.*)#.*/\1/' @@ -53,20 +63,6 @@ get_user_configured_dump_disk() return }
-is_user_configured_dump_target() -{ - local _target - - if is_ssh_dump_target || is_nfs_dump_target; then - return 0 - fi - - _target=$(egrep "^ext[234]|^xfs|^btrfs|^minix|^raw" /etc/kdump.conf 2>/dev/null |awk '{print $2}') - [ -n "$_target" ] && return 0 - - return 1 -} - get_root_fs_device() { local _target diff --git a/mkdumprd b/mkdumprd index adf9167..6916de4 100644 --- a/mkdumprd +++ b/mkdumprd @@ -325,24 +325,29 @@ get_block_dump_target() [ -b "$_target" ] && echo $(to_dev_name $_target) }
-# If no dump disk is specified make sure /var/crash is not mounted on a -# separate disk. -check_block_dump_target() +#handle the case user does not specify the dump target explicitly +handle_default_dump_target() { local _target local _mntpoint + local _fstype
is_user_configured_dump_target && return
- _target=$(get_root_fs_device) - if [ -b "$_target" ]; then - mkdir -p $SAVE_PATH - _mntpoint=`df $SAVE_PATH | tail -1 | awk '{print $NF}'` - if [ "$_mntpoint" != "/" ]; then - perror "No dump target specified. Default dump target is rootfs block device." - perror "But dump path $SAVE_PATH is not backed by rootfs block device. " - perror_exit "Either explicitly specify a dump target or specify a dump path backed by rootfs block device" + check_save_path_fs $SAVE_PATH + + _mntpoint=$(get_mntpoint_from_path $SAVE_PATH) + _target=$(get_target_from_path $SAVE_PATH) + if [ "$_mntpoint" != "/" ]; then + SAVE_PATH=${SAVE_PATH##"$_mntpoint"} + _fstype=$(get_fs_type_from_target $_target) + + if [ "$_fstype" = "nfs" ]; then + add_dracut_module "nfs" fi + + add_mount "$_target" + check_size fs $_target fi }
@@ -469,8 +474,6 @@ check_crypt() return 1 }
-check_block_dump_target - if ! check_resettable; then exit 1 fi @@ -548,6 +551,8 @@ do esac done < $conf_file
+handle_default_dump_target + if [ -n "$extra_modules" ] then add_dracut_arg "--add-drivers" "$extra_modules"
If default target is a separate disk, the related information need be stored in /etc/kdump.conf of kdump initramfs. This includes the disk info which will help to deduce the dump_code and path which the vmcore will be written into.
Signed-off-by: Baoquan He bhe@redhat.com --- dracut-module-setup.sh | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index bdadf7c..4c95e3d 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -261,6 +261,37 @@ kdump_install_net() { fi }
+default_dump_target_install_conf() +{ + local _target _fstype + local _s _t + local _mntpoint + local _path _save_path + + is_user_configured_dump_target && return + + _save_path=$(grep ^path "/etc/kdump.conf"| cut -d' ' -f2) + [ -z "$_save_path" ] && _save_path=$DEFAULT_PATH + + _mntpoint=$(get_mntpoint_from_path $_save_path) + _target=$(get_target_from_path $_save_path) + if [ "$_mntpoint" != "/" ]; then + _fstype=$(get_fs_type_from_target $_target) + + if [ "$_fstype" = "nfs" ];then + kdump_install_net "$_target" + else + _target=$(kdump_to_udev_name $_target) + fi + + echo "$_fstype $_target" >> /tmp/$$-kdump.conf + + _path=${_save_path##"$_mntpoint"} + sed -i -e "s#$_save_path#$_path#" /tmp/$$-kdump.conf + fi + +} + #install kdump.conf and what user specifies in kdump.conf kdump_install_conf() { sed -ne '/^#/!p' /etc/kdump.conf > /tmp/$$-kdump.conf @@ -285,6 +316,8 @@ kdump_install_conf() { esac done < /etc/kdump.conf
+ default_dump_target_install_conf + kdump_check_fence_kdump inst "/tmp/$$-kdump.conf" "/etc/kdump.conf" rm -f /tmp/$$-kdump.conf
On 03/31/14 at 03:17pm, Baoquan He wrote:
If default target is a separate disk, the related information need be stored in /etc/kdump.conf of kdump initramfs. This includes the disk info which will help to deduce the dump_code and path which the vmcore will be written into.
Signed-off-by: Baoquan He bhe@redhat.com
dracut-module-setup.sh | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index bdadf7c..4c95e3d 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -261,6 +261,37 @@ kdump_install_net() { fi }
+default_dump_target_install_conf() +{
- local _target _fstype
- local _s _t
- local _mntpoint
- local _path _save_path
- is_user_configured_dump_target && return
- _save_path=$(grep ^path "/etc/kdump.conf"| cut -d' ' -f2)
- [ -z "$_save_path" ] && _save_path=$DEFAULT_PATH
- _mntpoint=$(get_mntpoint_from_path $_save_path)
- _target=$(get_target_from_path $_save_path)
- if [ "$_mntpoint" != "/" ]; then
_fstype=$(get_fs_type_from_target $_target)
if [ "$_fstype" = "nfs" ];then
kdump_install_net "$_target"
$_fstype could be "nfs4" (I found this on my setup) and kdump will fail. You need to handle this "nfs4" case as well.
Thanks WANG Chao
else
_target=$(kdump_to_udev_name $_target)
fi
echo "$_fstype $_target" >> /tmp/$$-kdump.conf
_path=${_save_path##"$_mntpoint"}
sed -i -e "s#$_save_path#$_path#" /tmp/$$-kdump.conf
- fi
+}
#install kdump.conf and what user specifies in kdump.conf kdump_install_conf() { sed -ne '/^#/!p' /etc/kdump.conf > /tmp/$$-kdump.conf @@ -285,6 +316,8 @@ kdump_install_conf() { esac done < /etc/kdump.conf
- default_dump_target_install_conf
- kdump_check_fence_kdump inst "/tmp/$$-kdump.conf" "/etc/kdump.conf" rm -f /tmp/$$-kdump.conf
-- 1.8.5.3
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 04/03/14 at 02:32pm, WANG Chao wrote:
On 03/31/14 at 03:17pm, Baoquan He wrote:
If default target is a separate disk, the related information need be stored in /etc/kdump.conf of kdump initramfs. This includes the disk info which will help to deduce the dump_code and path which the vmcore will be written into.
Signed-off-by: Baoquan He bhe@redhat.com
dracut-module-setup.sh | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index bdadf7c..4c95e3d 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -261,6 +261,37 @@ kdump_install_net() { fi }
+default_dump_target_install_conf() +{
- local _target _fstype
- local _s _t
- local _mntpoint
- local _path _save_path
- is_user_configured_dump_target && return
- _save_path=$(grep ^path "/etc/kdump.conf"| cut -d' ' -f2)
- [ -z "$_save_path" ] && _save_path=$DEFAULT_PATH
- _mntpoint=$(get_mntpoint_from_path $_save_path)
- _target=$(get_target_from_path $_save_path)
- if [ "$_mntpoint" != "/" ]; then
_fstype=$(get_fs_type_from_target $_target)
if [ "$_fstype" = "nfs" ];then
kdump_install_net "$_target"
$_fstype could be "nfs4" (I found this on my setup) and kdump will fail. You need to handle this "nfs4" case as well.
To be more specific, if I run findmnt on my setup, I will have:
TARGET SOURCE FSTYPE OPTIONS /mnt/nfs 192.168.122.1:/mnt/testarea/nfs nfs4 rw,relatime,vers=4.0,rsize=10485
Thanks WANG Chao
else
_target=$(kdump_to_udev_name $_target)
fi
echo "$_fstype $_target" >> /tmp/$$-kdump.conf
_path=${_save_path##"$_mntpoint"}
sed -i -e "s#$_save_path#$_path#" /tmp/$$-kdump.conf
- fi
+}
#install kdump.conf and what user specifies in kdump.conf kdump_install_conf() { sed -ne '/^#/!p' /etc/kdump.conf > /tmp/$$-kdump.conf @@ -285,6 +316,8 @@ kdump_install_conf() { esac done < /etc/kdump.conf
- default_dump_target_install_conf
- kdump_check_fence_kdump inst "/tmp/$$-kdump.conf" "/etc/kdump.conf" rm -f /tmp/$$-kdump.conf
-- 1.8.5.3
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 04/03/14 at 02:32pm, WANG Chao wrote:
On 03/31/14 at 03:17pm, Baoquan He wrote:
+default_dump_target_install_conf() +{
- local _target _fstype
- local _s _t
- local _mntpoint
- local _path _save_path
- is_user_configured_dump_target && return
- _save_path=$(grep ^path "/etc/kdump.conf"| cut -d' ' -f2)
- [ -z "$_save_path" ] && _save_path=$DEFAULT_PATH
- _mntpoint=$(get_mntpoint_from_path $_save_path)
- _target=$(get_target_from_path $_save_path)
- if [ "$_mntpoint" != "/" ]; then
_fstype=$(get_fs_type_from_target $_target)
if [ "$_fstype" = "nfs" ];then
kdump_install_net "$_target"
$_fstype could be "nfs4" (I found this on my setup) and kdump will fail. You need to handle this "nfs4" case as well.
Good catch, chao. I used rhel7 client and rhel5 server to test, then fstype is always nfs when I execute findmnt. When use rhel7 client and fedora server, fstype is nfs4 when execute findmnt.
Hi Steve,
So from v4, has the rule been changed? It will return nfs4 or nfs, why not doing like before?
I am not sure who is the maintainer of util-linux which contains findmnt, do you know this?
Thanks Baoquan
Thanks WANG Chao
else
_target=$(kdump_to_udev_name $_target)
fi
echo "$_fstype $_target" >> /tmp/$$-kdump.conf
_path=${_save_path##"$_mntpoint"}
sed -i -e "s#$_save_path#$_path#" /tmp/$$-kdump.conf
- fi
+}
My apologies for the delayed response... I was traveling last week...
On 04/03/2014 02:58 AM, Baoquan He wrote:
On 04/03/14 at 02:32pm, WANG Chao wrote:
On 03/31/14 at 03:17pm, Baoquan He wrote:
+default_dump_target_install_conf() +{
- local _target _fstype
- local _s _t
- local _mntpoint
- local _path _save_path
- is_user_configured_dump_target && return
- _save_path=$(grep ^path "/etc/kdump.conf"| cut -d' ' -f2)
- [ -z "$_save_path" ] && _save_path=$DEFAULT_PATH
- _mntpoint=$(get_mntpoint_from_path $_save_path)
- _target=$(get_target_from_path $_save_path)
- if [ "$_mntpoint" != "/" ]; then
_fstype=$(get_fs_type_from_target $_target)
if [ "$_fstype" = "nfs" ];then
kdump_install_net "$_target"
$_fstype could be "nfs4" (I found this on my setup) and kdump will fail. You need to handle this "nfs4" case as well.
Good catch, chao. I used rhel7 client and rhel5 server to test, then fstype is always nfs when I execute findmnt. When use rhel7 client and fedora server, fstype is nfs4 when execute findmnt.
Hi Steve,
So from v4, has the rule been changed? It will return nfs4 or nfs, why not doing like before?
Well, I'm guess its because the default protocol has changed from v3 to v4 but you should have seen this problem with RHEL6 as well since when the default protocol changed.
I am not sure who is the maintainer of util-linux which contains findmnt, do you know this?
Karel Zak is the maintainer, I've cc-ed him....
steved.
Thanks Baoquan
Thanks WANG Chao
else
_target=$(kdump_to_udev_name $_target)
fi
echo "$_fstype $_target" >> /tmp/$$-kdump.conf
_path=${_save_path##"$_mntpoint"}
sed -i -e "s#$_save_path#$_path#" /tmp/$$-kdump.conf
- fi
+}
On Mon, Apr 07, 2014 at 08:18:28AM -0400, Steve Dickson wrote:
My apologies for the delayed response... I was traveling last week...
On 04/03/2014 02:58 AM, Baoquan He wrote:
On 04/03/14 at 02:32pm, WANG Chao wrote:
On 03/31/14 at 03:17pm, Baoquan He wrote:
+default_dump_target_install_conf() +{
- local _target _fstype
- local _s _t
- local _mntpoint
- local _path _save_path
- is_user_configured_dump_target && return
- _save_path=$(grep ^path "/etc/kdump.conf"| cut -d' ' -f2)
- [ -z "$_save_path" ] && _save_path=$DEFAULT_PATH
- _mntpoint=$(get_mntpoint_from_path $_save_path)
- _target=$(get_target_from_path $_save_path)
- if [ "$_mntpoint" != "/" ]; then
_fstype=$(get_fs_type_from_target $_target)
if [ "$_fstype" = "nfs" ];then
kdump_install_net "$_target"
$_fstype could be "nfs4" (I found this on my setup) and kdump will fail. You need to handle this "nfs4" case as well.
Good catch, chao. I used rhel7 client and rhel5 server to test, then fstype is always nfs when I execute findmnt. When use rhel7 client and fedora server, fstype is nfs4 when execute findmnt.
Hi Steve,
So from v4, has the rule been changed? It will return nfs4 or nfs, why not doing like before?
Well, I'm guess its because the default protocol has changed from v3 to v4 but you should have seen this problem with RHEL6 as well since when the default protocol changed.
I am not sure who is the maintainer of util-linux which contains findmnt, do you know this?
Karel Zak is the maintainer, I've cc-ed him....
findmnt reads /proc/self/mountinfo
Karel
On 04/07/14 at 03:06pm, Karel Zak wrote:
On Mon, Apr 07, 2014 at 08:18:28AM -0400, Steve Dickson wrote:
My apologies for the delayed response... I was traveling last week...
On 04/03/2014 02:58 AM, Baoquan He wrote:
On 04/03/14 at 02:32pm, WANG Chao wrote:
On 03/31/14 at 03:17pm, Baoquan He wrote:
$_fstype could be "nfs4" (I found this on my setup) and kdump will fail. You need to handle this "nfs4" case as well.
Good catch, chao. I used rhel7 client and rhel5 server to test, then fstype is always nfs when I execute findmnt. When use rhel7 client and fedora server, fstype is nfs4 when execute findmnt.
Hi Steve,
So from v4, has the rule been changed? It will return nfs4 or nfs, why not doing like before?
Well, I'm guess its because the default protocol has changed from v3 to v4 but you should have seen this problem with RHEL6 as well since when the default protocol changed.
Thanks, Steve and Karel
So now in nfs file system, nfsv1/2/3 use the same file_system_type, namely &nfs_fs_type. However in nfsv4, it uses its onw file_system_type like below. I am gonna to ask if this can be changed back to be "nfs" just like the previous 3 version.
static struct file_system_type nfs4_remote_fs_type = { .owner = THIS_MODULE, .name = "nfs4", ~~~~~~~ This gonna be the fs type in /proc/self/mountinfo
.mount = nfs4_remote_mount, .kill_sb = nfs_kill_super, .fs_flags = FS_RENAME_DOES_D_MOVE|FS_BINARY_MOUNTDATA, };
static struct file_system_type nfs4_remote_referral_fs_type = { .owner = THIS_MODULE, .name = "nfs4", .mount = nfs4_remote_referral_mount, .kill_sb = nfs_kill_super, .fs_flags = FS_RENAME_DOES_D_MOVE|FS_BINARY_MOUNTDATA, };
struct file_system_type nfs4_referral_fs_type = { .owner = THIS_MODULE, .name = "nfs4", .mount = nfs4_referral_mount, .kill_sb = nfs_kill_super, .fs_flags = FS_RENAME_DOES_D_MOVE|FS_BINARY_MOUNTDATA, };
Thanks Baoquan
I am not sure who is the maintainer of util-linux which contains findmnt, do you know this?
Karel Zak is the maintainer, I've cc-ed him....
findmnt reads /proc/self/mountinfo
On 04/07/2014 10:35 PM, Baoquan He wrote:
On 04/07/14 at 03:06pm, Karel Zak wrote:
On Mon, Apr 07, 2014 at 08:18:28AM -0400, Steve Dickson wrote:
My apologies for the delayed response... I was traveling last week...
On 04/03/2014 02:58 AM, Baoquan He wrote:
On 04/03/14 at 02:32pm, WANG Chao wrote:
On 03/31/14 at 03:17pm, Baoquan He wrote:
$_fstype could be "nfs4" (I found this on my setup) and kdump will fail. You need to handle this "nfs4" case as well.
Good catch, chao. I used rhel7 client and rhel5 server to test, then fstype is always nfs when I execute findmnt. When use rhel7 client and fedora server, fstype is nfs4 when execute findmnt.
Hi Steve,
So from v4, has the rule been changed? It will return nfs4 or nfs, why not doing like before?
Well, I'm guess its because the default protocol has changed from v3 to v4 but you should have seen this problem with RHEL6 as well since when the default protocol changed.
Thanks, Steve and Karel
So now in nfs file system, nfsv1/2/3 use the same file_system_type, namely &nfs_fs_type. However in nfsv4, it uses its onw file_system_type like below. I am gonna to ask if this can be changed back to be "nfs" just like the previous 3 version.
The issue here is the fact the NFS versions were broken out into separate kernel modules in RHEL7. This is actually the reason we could turn off v2 support... So the option of changing it back will not work since two different modules can have the same name.
I would suggest you adapt you script to handle both....
steved.
static struct file_system_type nfs4_remote_fs_type = { .owner = THIS_MODULE, .name = "nfs4", ~~~~~~~ This gonna be the fs type in /proc/self/mountinfo
.mount = nfs4_remote_mount, .kill_sb = nfs_kill_super, .fs_flags = FS_RENAME_DOES_D_MOVE|FS_BINARY_MOUNTDATA,
};
static struct file_system_type nfs4_remote_referral_fs_type = { .owner = THIS_MODULE, .name = "nfs4", .mount = nfs4_remote_referral_mount, .kill_sb = nfs_kill_super, .fs_flags = FS_RENAME_DOES_D_MOVE|FS_BINARY_MOUNTDATA, };
struct file_system_type nfs4_referral_fs_type = { .owner = THIS_MODULE, .name = "nfs4", .mount = nfs4_referral_mount, .kill_sb = nfs_kill_super, .fs_flags = FS_RENAME_DOES_D_MOVE|FS_BINARY_MOUNTDATA, };
Thanks Baoquan
I am not sure who is the maintainer of util-linux which contains findmnt, do you know this?
Karel Zak is the maintainer, I've cc-ed him....
findmnt reads /proc/self/mountinfo
On 04/08/14 at 08:41am, Steve Dickson wrote:
On 04/07/2014 10:35 PM, Baoquan He wrote:
Thanks, Steve and Karel
So now in nfs file system, nfsv1/2/3 use the same file_system_type, namely &nfs_fs_type. However in nfsv4, it uses its onw file_system_type like below. I am gonna to ask if this can be changed back to be "nfs" just like the previous 3 version.
The issue here is the fact the NFS versions were broken out into separate kernel modules in RHEL7. This is actually the reason we could turn off v2 support... So the option of changing it back will not work since two different modules can have the same name.
I would suggest you adapt you script to handle both....
Hi Steve,
Yeah, I tried changing kernel code, then mount.nfs failed immediately. I will adapt my script as you suggested. But I will create a bug to track this issue. Maybe whatever the version of nfs is, the type should be nfs, people can check its version from the mount option, and that truly has a option to show version, namely v3 or v4.
Thanks Baoquan
steved.
On 04/08/2014 10:56 PM, Baoquan He wrote:
On 04/08/14 at 08:41am, Steve Dickson wrote:
On 04/07/2014 10:35 PM, Baoquan He wrote:
Thanks, Steve and Karel
So now in nfs file system, nfsv1/2/3 use the same file_system_type, namely &nfs_fs_type. However in nfsv4, it uses its onw file_system_type like below. I am gonna to ask if this can be changed back to be "nfs" just like the previous 3 version.
The issue here is the fact the NFS versions were broken out into separate kernel modules in RHEL7. This is actually the reason we could turn off v2 support... So the option of changing it back will not work since two different modules can have the same name.
I would suggest you adapt you script to handle both....
Hi Steve,
Yeah, I tried changing kernel code, then mount.nfs failed immediately. I will adapt my script as you suggested. But I will create a bug to track this issue. Maybe whatever the version of nfs is, the type should be nfs, people can check its version from the mount option, and that truly has a option to show version, namely v3 or v4.
Well there is not much we can do about what is being put into /proc/self/mountinfo... But... Looking at what is being put /proc/self/mountinfo.... nfs == v3 and nfs4 == v4 Those are the *only* two entries... So I don't see why a simple change to your script like:
if [ "$_fstype" = "nfs" -o "$_fstype" = "nfs4" ];then kdump_install_net "$_target"
would not fix the problem?
steved.
On 04/09/14 at 01:05pm, Steve Dickson wrote:
On 04/08/2014 10:56 PM, Baoquan He wrote:
On 04/08/14 at 08:41am, Steve Dickson wrote:
On 04/07/2014 10:35 PM, Baoquan He wrote:
Thanks, Steve and Karel
So now in nfs file system, nfsv1/2/3 use the same file_system_type, namely &nfs_fs_type. However in nfsv4, it uses its onw file_system_type like below. I am gonna to ask if this can be changed back to be "nfs" just like the previous 3 version.
The issue here is the fact the NFS versions were broken out into separate kernel modules in RHEL7. This is actually the reason we could turn off v2 support... So the option of changing it back will not work since two different modules can have the same name.
I would suggest you adapt you script to handle both....
Hi Steve,
Yeah, I tried changing kernel code, then mount.nfs failed immediately. I will adapt my script as you suggested. But I will create a bug to track this issue. Maybe whatever the version of nfs is, the type should be nfs, people can check its version from the mount option, and that truly has a option to show version, namely v3 or v4.
Well there is not much we can do about what is being put into /proc/self/mountinfo... But... Looking at what is being put /proc/self/mountinfo.... nfs == v3 and nfs4 == v4 Those are the *only* two entries... So I don't see why a simple change to your script like:
if [ "$_fstype" = "nfs" -o "$_fstype" = "nfs4" ];then kdump_install_net "$_target"
would not fix the problem?
Yeah, it's easy to adapt kdump script. But I don't think only kdump encounter this problem. This is more likely a generic issue, why fstype of nfs3 is nfs, nfs4 is nfs4, why user have to know this is because kernel separate a implementation for nfs4.
Anyway I will make change in kdump script, also a bug for this issue has been created, its priority is set very low.
https://bugzilla.redhat.com/show_bug.cgi?id=1085623
Thanks Baoquan
steved.
Trimming the cc-list just a bit..
On 04/09/2014 09:48 PM, Baoquan He wrote:
Yeah, it's easy to adapt kdump script. But I don't think only kdump encounter this problem. This is more likely a generic issue, why fstype of nfs3 is nfs, nfs4 is nfs4, why user have to know this is because kernel separate a implementation for nfs4.
Fair enough... This could balloon into a bigger problem... Only time will tell...
Anyway I will make change in kdump script, also a bug for this issue has been created, its priority is set very low.
I saw that... but you know what "low priority" means... ;-)
On a side note... There is a problem with kdump dumping to a legacy AIX server https://bugzilla.redhat.com/show_bug.cgi?id=1075986
To whom should I add to that bz that can tell me how kdump does an NFS mount. In a nutshell... native mounts works but mount via kdump do not...
steved.
On 04/11/14 at 03:49pm, Steve Dickson wrote:
Trimming the cc-list just a bit..
On 04/09/2014 09:48 PM, Baoquan He wrote:
Yeah, it's easy to adapt kdump script. But I don't think only kdump encounter this problem. This is more likely a generic issue, why fstype of nfs3 is nfs, nfs4 is nfs4, why user have to know this is because kernel separate a implementation for nfs4.
Fair enough... This could balloon into a bigger problem... Only time will tell...
Anyway I will make change in kdump script, also a bug for this issue has been created, its priority is set very low.
I saw that... but you know what "low priority" means... ;-)
Got it. Just thought it can not be solved currently, but still want them to hear what we are requiring.
On a side note... There is a problem with kdump dumping to a legacy AIX server https://bugzilla.redhat.com/show_bug.cgi?id=1075986
To whom should I add to that bz that can tell me how kdump does an NFS mount. In a nutshell... native mounts works but mount via kdump do not..
I added comments in that bz, please check it. .
steved.
On 04/11/2014 08:02 PM, Baoquan He wrote:
On 04/11/14 at 03:49pm, Steve Dickson wrote:
Trimming the cc-list just a bit..
On 04/09/2014 09:48 PM, Baoquan He wrote:
Yeah, it's easy to adapt kdump script. But I don't think only kdump encounter this problem. This is more likely a generic issue, why fstype of nfs3 is nfs, nfs4 is nfs4, why user have to know this is because kernel separate a implementation for nfs4.
Fair enough... This could balloon into a bigger problem... Only time will tell...
Anyway I will make change in kdump script, also a bug for this issue has been created, its priority is set very low.
I saw that... but you know what "low priority" means... ;-)
Got it. Just thought it can not be solved currently, but still want them to hear what we are requiring.
On a side note... There is a problem with kdump dumping to a legacy AIX server https://bugzilla.redhat.com/show_bug.cgi?id=1075986
To whom should I add to that bz that can tell me how kdump does an NFS mount. In a nutshell... native mounts works but mount via kdump do not..
I added comments in that bz, please check it.
I added a comment as well... I'm thinking you should let the mount command figure this out... Its pretty good at that... ;-)
steved.
.
steved.
In case no target is specified explicitly in /etc/kdump.conf, the behavior of path is changed, a check need be taken to see if any separate file system is mounted on any tier of 'path', and also to take the relevant action. Now the path section need be renewed accordingly.
Signed-off-by: Baoquan He bhe@redhat.com --- kexec-kdump-howto.txt | 50 +++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 39 insertions(+), 11 deletions(-)
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt index 7ffeab9..5582e40 100644 --- a/kexec-kdump-howto.txt +++ b/kexec-kdump-howto.txt @@ -364,18 +364,46 @@ to send over the necessary ssh key file. Restart the kdump service via '/sbin/systemctl restart kdump.service' to commit this change to your kdump initrd.
Path +==== +"path" represents the file system path in which vmcore will be saved. In +fact kdump creates a directory $hostip-$date with-in "path" and saves +vmcore there. So practically dump is saved in $path/$hostip-$date/. To +simplify discussion further, if we say dump will be saved in $path, it +is implied that kdump will create another directory inside path and +save vmcore there. + +If a dump target is specified in kdump.conf, then "path" is relative to the +specified dump target. For example, if dump target is "ext4 /dev/sda", then +dump will be saved in "$path" directory on /dev/sda. + +Same is the case for nfs dump. If user specified "nfs foo.com:/export/tmp/" +as dump target, then dump will effectively be saved in +"foo.com:/export/tmp/var/crash/" directory. + +Interpretation of path changes a bit if user has not specified a dump +target explicitly in kdump.conf. In this case, "path" represents the +absolute path from root. And dump target and adjusted path are arrived +at automatically depending on what's mounted in the current system. + +Following are few examples. + +path /var/crash/ +---------------- +Assuming there is no disk mounted on /var/ or on /var/crash, dump will +be saved on disk backing rootfs in directory /var/crash. + +path /var/crash/ (A separate disk mounted on /var) +-------------------------------------------------- +Say a disk /dev/sdb is mouted on /var. In this case dump target will +become /dev/sdb and path will become "/crash" and dump will be saved +on "sdb:/crash/" directory. + +path /var/crash/ (NFS mounted on /var) +------------------------------------- +Say foo.com:/export/tmp is mounted on /var. In this case dump target is +nfs server and path will be adjusted to "/crash" and dump will be saved to +foo.com:/export/tmp/crash/ directory.
-By default, local file system vmcore files are written to /var/crash/%DATE -on the local system, ssh/scp dumps to /var/crash/%HOST-%DATE on the target -system, dedicated file system partition dumps to ./var/crash/%DATE, and -NFS dumps to ./var/crash/%HOST-%DATE, the latter two both relative to -their respective mount points within the kdump initrd (usually /mnt). The -'/var/crash' portion of the path can be overridden using kdump.conf's 'path' -variable, should you wish to write the vmcore out to a different location. For -example, 'path /data/coredumps' would lead to vmcore files being written to -/data/coredumps/%DATE if you were dumping to your local file system. Note -that the path option is ingnored if your kdump configuration results in the -core being saved from the initscripts in the root filesystem.
Kdump Post-Capture Executable
In case no target is specified explicitly in /etc/kdump.conf, the behavior of path is changed, a check need be taken to see if any separate file system is mounted on any tier of 'path', and also to take the relevant action. Now the path section need be renewed for kdump.conf and its man page accordingly.
Signed-off-by: Baoquan He bhe@redhat.com --- kdump.conf | 15 ++++++++++++--- kdump.conf.5 | 10 +++++++++- 2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/kdump.conf b/kdump.conf index a106462..d6f1123 100644 --- a/kdump.conf +++ b/kdump.conf @@ -35,9 +35,18 @@ # such as /dev/vg/<devname>. # Otherwise it's suggested to use label or uuid. # -# path <path> - Append path to the filesystem device which you are -# dumping to. Ignored for raw device dumps. -# If unset, will default to /var/crash. +# path <path> - "path" represents the file system path in which +# vmcore will be saved. If a dump target is specified +# in kdump.conf, then "path" is relative to the +# specified dump target. Interpretation of path +# changes a bit if user has not specified a dump +# target explicitly in kdump.conf. In this case, +# "path" represents the absolute path from root. +# And dump target and adjusted path are arrived +# at automatically depending on what's mounted +# in the current system. +# Ignored for raw device dumps. If unset, will +# default to /var/crash. # # core_collector <command> <options> # - This allows you to specify the command to copy diff --git a/kdump.conf.5 b/kdump.conf.5 index 7eaf9dd..c338342 100644 --- a/kdump.conf.5 +++ b/kdump.conf.5 @@ -62,7 +62,15 @@ or uuid. It's recommended to use persistent device names such as
.B path <path> .RS -Append path to the filesystem device which you are dumping to. +"path" represents the file system path in which vmcore will be saved. +If a dump target is specified in kdump.conf, then "path" is relative to the +specified dump target. +.PP +Interpretation of path changes a bit if user has not specified a dump +target explicitly in kdump.conf. In this case, "path" represents the +absolute path from root. And dump target and adjusted path are arrived +at automatically depending on what's mounted in the current system. +.PP Ignored for raw device dumps. If unset, will default to /var/crash. .RE
On Mon, Mar 31, 2014 at 03:17:01PM +0800, Baoquan He wrote:
These utility function will be shared by several files, they are all operation related to mount stuff.
Meantime define DEFAULT_PATH="/var/crash".
Signed-off-by: Baoquan He bhe@redhat.com Acked-by: Vivek Goyal vgoyal@redhat.com
This patch series looks good to me. Thanks for the work Bao.
Acked-by: Vivek Goyal vgoyal@redhat.com
Vivek
kdump-lib.sh | 21 +++++++++++++++++++++ mkdumprd | 2 +- 2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index de32650..bf57a91 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -3,6 +3,7 @@ # Kdump common variables and functions #
+DEFAULT_PATH="/var/crash/" FENCE_KDUMP_CONFIG="/etc/sysconfig/fence_kdump" FENCE_KDUMP_SEND="/usr/libexec/fence_kdump_send" FENCE_KDUMP_NODES="/etc/fence_kdump_nodes" @@ -75,3 +76,23 @@ get_root_fs_device() return }
+get_mntpoint_from_path() +{
- echo $(df $1 | tail -1 | awk '{print $NF}')
+}
+get_target_from_path() +{
- echo $(df $1 | tail -1 | awk '{print $1}')
+}
+get_fs_type_from_target() +{
- echo $(findmnt -k -f -n -r -o FSTYPE $1)
+}
+get_mntpoint_from_target() +{
- echo $(findmnt -k -f -n -r -o TARGET $1)
+}
diff --git a/mkdumprd b/mkdumprd index 84f1e18..3849866 100644 --- a/mkdumprd +++ b/mkdumprd @@ -12,7 +12,7 @@ export IN_KDUMP=1 conf_file="/etc/kdump.conf" SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa" SAVE_PATH=$(grep ^path $conf_file| cut -d' ' -f2) -[ -z "$SAVE_PATH" ] && SAVE_PATH="/var/crash" +[ -z "$SAVE_PATH" ] && SAVE_PATH=$DEFAULT_PATH extra_modules="" dracut_args=("--hostonly" "-o" "plymouth dash resume") OVERRIDE_RESETTABLE=0 -- 1.8.5.3
These utility function will be shared by several files, they are all operation related to mount stuff.
v5-> v6: Since in rhel7 nfs4 becomes default nfs version, and its fstype is nfs4. So change the implementation of get_fs_type_from_target(), whatever fstype returned from findmount, just echo nfs as fstype for all nfs version.
Meantime define DEFAULT_PATH="/var/crash".
Signed-off-by: Baoquan He bhe@redhat.com --- kdump-lib.sh | 24 ++++++++++++++++++++++++ mkdumprd | 2 +- 2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index de32650..9e5ed1d 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -3,6 +3,7 @@ # Kdump common variables and functions #
+DEFAULT_PATH="/var/crash/" FENCE_KDUMP_CONFIG="/etc/sysconfig/fence_kdump" FENCE_KDUMP_SEND="/usr/libexec/fence_kdump_send" FENCE_KDUMP_NODES="/etc/fence_kdump_nodes" @@ -75,3 +76,26 @@ get_root_fs_device() return }
+get_mntpoint_from_path() +{ + echo $(df $1 | tail -1 | awk '{print $NF}') +} + +get_target_from_path() +{ + echo $(df $1 | tail -1 | awk '{print $1}') +} + +get_fs_type_from_target() +{ + local fstype + fstype=$(findmnt -k -f -n -r -o FSTYPE $1) + [[ $fstype = *nfs* ]] && fstype="nfs" + echo $fstype +} + +get_mntpoint_from_target() +{ + echo $(findmnt -k -f -n -r -o TARGET $1) +} + diff --git a/mkdumprd b/mkdumprd index 84f1e18..3849866 100644 --- a/mkdumprd +++ b/mkdumprd @@ -12,7 +12,7 @@ export IN_KDUMP=1 conf_file="/etc/kdump.conf" SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa" SAVE_PATH=$(grep ^path $conf_file| cut -d' ' -f2) -[ -z "$SAVE_PATH" ] && SAVE_PATH="/var/crash" +[ -z "$SAVE_PATH" ] && SAVE_PATH=$DEFAULT_PATH extra_modules="" dracut_args=("--hostonly" "-o" "plymouth dash resume") OVERRIDE_RESETTABLE=0
On 04/09/14 at 01:25pm, Baoquan He wrote:
These utility function will be shared by several files, they are all operation related to mount stuff.
v5-> v6: Since in rhel7 nfs4 becomes default nfs version, and its fstype is nfs4. So change the implementation of get_fs_type_from_target(), whatever fstype returned from findmount, just echo nfs as fstype for all nfs version.
Meantime define DEFAULT_PATH="/var/crash".
Signed-off-by: Baoquan He bhe@redhat.com
Hi, Bao
Things got changed since I committed Martin's patches for generic cluster. I can't apply your patchset.
Could you rebase your patch on top of master branch please?
Thanks WANG Chao
kdump-lib.sh | 24 ++++++++++++++++++++++++ mkdumprd | 2 +- 2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index de32650..9e5ed1d 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -3,6 +3,7 @@ # Kdump common variables and functions #
+DEFAULT_PATH="/var/crash/" FENCE_KDUMP_CONFIG="/etc/sysconfig/fence_kdump" FENCE_KDUMP_SEND="/usr/libexec/fence_kdump_send" FENCE_KDUMP_NODES="/etc/fence_kdump_nodes" @@ -75,3 +76,26 @@ get_root_fs_device() return }
+get_mntpoint_from_path() +{
- echo $(df $1 | tail -1 | awk '{print $NF}')
+}
+get_target_from_path() +{
- echo $(df $1 | tail -1 | awk '{print $1}')
+}
+get_fs_type_from_target() +{
- local fstype
- fstype=$(findmnt -k -f -n -r -o FSTYPE $1)
- [[ $fstype = *nfs* ]] && fstype="nfs"
- echo $fstype
+}
+get_mntpoint_from_target() +{
- echo $(findmnt -k -f -n -r -o TARGET $1)
+}
diff --git a/mkdumprd b/mkdumprd index 84f1e18..3849866 100644 --- a/mkdumprd +++ b/mkdumprd @@ -12,7 +12,7 @@ export IN_KDUMP=1 conf_file="/etc/kdump.conf" SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa" SAVE_PATH=$(grep ^path $conf_file| cut -d' ' -f2) -[ -z "$SAVE_PATH" ] && SAVE_PATH="/var/crash" +[ -z "$SAVE_PATH" ] && SAVE_PATH=$DEFAULT_PATH extra_modules="" dracut_args=("--hostonly" "-o" "plymouth dash resume") OVERRIDE_RESETTABLE=0 -- 1.8.5.3
On Wed, Apr 09, 2014 at 01:25:04PM +0800, Baoquan He wrote:
[..]
+get_fs_type_from_target() +{
- local fstype
- fstype=$(findmnt -k -f -n -r -o FSTYPE $1)
- [[ $fstype = *nfs* ]] && fstype="nfs"
- echo $fstype
I think instead of resetting it here, take care of it in caller. Let this function return actual fstype.
Also *nfs* seems to be too generic. Now foonfsbar fs type will also match this search.
Why not check for exact version numbers and if need be provide an helper function.
is_fs_type_nfs() { if fstype==nfs or fstype==nfs4 reutrn 0 return 1 }
Thanks Vivek
On 04/09/14 at 11:49am, Vivek Goyal wrote:
On Wed, Apr 09, 2014 at 01:25:04PM +0800, Baoquan He wrote:
[..]
+get_fs_type_from_target() +{
- local fstype
- fstype=$(findmnt -k -f -n -r -o FSTYPE $1)
- [[ $fstype = *nfs* ]] && fstype="nfs"
- echo $fstype
I think instead of resetting it here, take care of it in caller. Let this function return actual fstype.
Also *nfs* seems to be too generic. Now foonfsbar fs type will also match this search.
Why not check for exact version numbers and if need be provide an helper function.
is_fs_type_nfs() { if fstype==nfs or fstype==nfs4 reutrn 0 return 1 }
Will change per your idea. Thanks, Vivek.
Thanks Vivek