On Sun, Feb 15, 2015 at 09:15:43PM +0800, Minfei Huang wrote:
[..]
> I'm not sure if I good understand the original problem, but
I'm sure
> that care about bind mounts is mistake ;-) If the problem is that
> dump is not in the filesystem root then you can try to check if the
> root of the filesystem is mounted somewhere else, but maybe the best
> would be avoid such fragile setup at all.
It is complicate for kdump, if we deal with the bind mounted. So in
order to simplify the process, how about add the bind mounted path to
the dump target, if the target is bind mounted?
Following is an example:
-bash-4.2# cat /etc/kdump.conf |grep ^path
path /var/crash
-bash-4.2# findmnt /var | tail -n 1 | awk '{print $2}'
/dev/mapper/atomicos-root[/ostree/deploy/rhel-atomic-host/var]
-bash-4.2# findmnt -v /var | tail -n 1 | awk '{print $2}'
/dev/mapper/atomicos-root
Then we can found it that the real path of dumping core is
/ostree/deploy/rhel-atomic-host/var/crash.
Here is the scratch path to fix this issue.
Minfei,
So what you are suggesting is that let us figure out where is the real
disk and path with-in disk which is mounted on "path" as specified in
kdump.conf.
I think that will work. So basically we will say that we will not ignore
bind mounts instead resolve the "path" to map to real disk and path
with-in disk. We just need to make sure that logic is generic enough that
it can detect and sort out even complicated cases of bind mounts like multiple
bind mounts.
mount /dev/foo /
mount /dev/foo1 /var
mount /dev/foo2 /var/crash
Thanks
Vivek