Re: FFS dump of snapshot (with LVM) - reboot

[Greg Troxel <gdt%lexort.com@localhost>]

Matthias Petermann <mp%petermann-it.de@localhost> writes:

> I am currently trying my luck with backing up various large FFS file
> systems (WAPBL enabled) using snapshots and the dump program.
>
> Under the following conditions, I have succeeded so far:
>
> * The file system resides on a GPT partition or is part of a disklabel
> that resides within a GPT / MBR partition
>
> * The WABPL journal is located outside the file system (created with
> newfs -O2 -s -64m /dev/....)
>
> * The backend store for the snapshot is outside the file system
>
> The procedure has proven itself:
>
> % fssconfig fss0 /data /var/snap/data 512 512m
> % dump -b64 -0auf /mnt/data.0.dump /dev/fss0
> % fssconfig -u
>
> Thereby a tmpfs is mounted under /var/snap. As long as the content of
> the file system to be backed up does not change in size during the dump
> run, the space is sufficient there. If this is not the case, the fss
> device will be unconfigured, and dump handles the error correctly.
>
> Now the problem: I have not been able to reliably dump file systems via
> this path, which are located in an LVM volume. Therefore my question:
> are there obvious facts that speak against it or have I not read the
> documentation correctly at this point? Or would that have to work
> theoretically? I have experienced in several cases that restarted
> without notice while dumping the computer.
>
> I would be very happy about your experiences and hints on this topic.

It could be that there is a locking problem with the combination of fss
and LVM that does not manifest with either alone.  (I am just making
that up; I have no prior reason to suspect it, other than your email.)
Or some other bug that presents only with both features at the same
time.

It does not sound like you are doing anything wrong, and if so it should
not result in a crash anyway.

I would advise running a kernel built with options DIAGNOSTIC, and
leaving the system running where you can see the console (so no X11).
Also ensure /var/cash has space and savecore=YES.  There is also DEBUG
and LOCKDEBUG, but I would try just DIAGNOSTIC first.

Assuming you are running netbsd-8, you might also try a -current kernel
(but without changing your netbsd-8 userland), to see if that is
different.  Sometimes bugs end up fixed in current, but the change that
fixed them is not applied to -8.