Hi Dave,
Thanks for your valuable feedback.
On 01/04/2016:05:03:27 PM, Dave Young wrote:
On 04/01/16 at 09:21am, Pratyush Anand wrote:
> Hi Xunlei,
>
> Thanks for your review.
>
> On 01/04/2016:09:51:50 AM, Xunlei Pang wrote:
> > On 2016/03/30 at 15:45, Pratyush Anand wrote:
> > > kdump also passes persistent device mapping as --mount or --device
argument
> > > of dracut. However this persistent id (UUID) is changed if dump target is
> > > re-formated.
> > > kdumpctl must have a mechanism to recognise this modification, so that
its
> > > service restart is able to rebuild initramfs.
> > >
> > > Testing:
> > > * When raw target is raid device, dracut argument is passed as --device
> > > '/dev/mapper/xxxxx', and in this case it does not force rebuild
after
> > > reformatting. vmcore save was also fine.
> > > * When raw target is an ide device, dracut argument is passed as --device
> > > '/dev/disk/by-uuid/xxxxx', and in this case it does force
rebuild after
> > > reformatting.
> > > * Similar test was also performed as ext4, xfs and btrfs file system
target.
> > >
> > > One of the test case's detailed illustration:
> > > a) Attach an IDE device, lets say it is /dev/sdb1
> > > b) Format it as ext4
> > > # mkfs.ext4 /dev/sdb1
> > > # blkid /dev/sdb1
> > > /dev/sdb1: UUID="21c7baff-e35d-49c7-aa08-0fba4513f5bf"
TYPE="ext4"
> > > c) Mount it into /mnt and create a var/crash directory in it.
> > > # mount /dev/sdb1 /mnt;mkdir /mnt/var;mkdir /mnt/var/crash
> > > d) Add following line in /etc/kdump.conf
> > > ext4 /dev/sdb1
> > > e) Restart kdumpctl
> > > # kdumpctl restart
> >
> > Should we make this more intelligent? i.e. open a daemon, if detecting such
> > modification(poll or better utilize some kernel notification mechanism), then
> > restart dump automatically without user's manual intervention.
>
> Yes, this is on agenda and will be done after active watchdog detection patches
> are also upstreamed.
We can keep it in mind, it will even increase the kdump scripts complexity.
If we automaticlly detect changes for filesystem, one will say how about detect
network changes as well. There are a lot of different cases for storage and networking
They will increase the complexity even more. Also we may have to add another systemd
service to handle it. Most of the daemon are written in C, shell may not be a good
choice, using bash we need a sleep/loop...
OK, that I can explore when will start implementing it. I would also be more
comfortable in writing C code :-).
How about handle these case by case and maybe we can do it only when there
are such reports in the future?
Yes, agreed.
~Pratyush