Hi Dave,
On 05/04/2016:03:34:35 PM, Dave Young wrote:
Hi, Pratyush
On 04/05/16 at 12:27pm, Pratyush Anand wrote:
> Hi Dave,
>
> On 05/04/2016:02:39:13 PM, Dave Young wrote:
> > Hi, Pratyush
> >
> > > > > +is_dump_target_modified()
> > > > > +{
> > > > > + target=$(egrep "^ext[234]|^xfs|^btrfs|^raw"
/etc/kdump.conf)
> > > >
> > > > All the vars should be local in the function
> > >
> > > I thought, by default they are local. OK.Will improve in V2.
> > >
> > > > btw use the function below should be better:
> > > > _target=$(local_fs_dump_target)
> > > >
> > > > raw is not necessary because we do not care the filesystem on it.
> > >
> > > I had thought of using it, but did not use as
> > > (1) We also need to take care of "raw". I agree it is filesystem
independent, but
> > > UUID of a /dev/sdxn device changes after any type of formatting. So, even
if
> > > /etc/kdump.conf has raw entry, it will not work if disk is re-formatted.
> >
> > It sounds odd to use "raw UUID=" in kdump.conf, but lvm volume name
should be
> > fine since it is persistent.
> >
> > Hmm, does that mean even if for "raw /dev/sdb1" in kdump.conf, kdump
still
> > uses UUID in kdump initrd in case there is a filesystem on /dev/sdb1?
>
> Yes. This is what I observed.
>
How about fix it to avoid "uuid" and "label" for raw devices? we can
use
persistent dev names other than filsystem label and uuid eg. by-id/ or
by-path/
So that even if the uuid changed we do not need to rebuild kdump initrd for
"raw" because raw devices do not care about the backing filesystem..
Seems reasonable.
OK, Will do.
Thanks for the feedback.
~Pratyush