Hi, Pratyush
On 04/01/16 at 02:57pm, Pratyush Anand wrote:
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 :-).
Ok, thanks a lot! We can do it if we have strong reason to do it later.
>
> >
> > 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
> _______________________________________________
> kexec mailing list
> kexec(a)lists.fedoraproject.org
>
http://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org