On 02/16/15 at 07:44pm, Vivek Goyal wrote:
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
Hi, Vivek!
Yes, I think it can simplify our working on the bind mounted issue.
Finding the real disk and path with-in disk is a simple way to solve the
bind mounted issue. It is complicated to sort out the mount point in 2nd
kernel, if the 1st kernel uses bind mounted.
Thanks
Minfei