Hello NetBSD-Users,after trying to backup from my WAPBL-enabled FFSv2 filesystems with dump every now and then, my memories of using FSS (-X option of dump) are not the very best. I had problems with it interacting with LVM a few years ago, resulting in sporadic crashes during backups and inconsistent filesystem state after the reboot. This was difficult for me to recreate at the time, and since then I've been forced to use dump without snapshots to keep my head above water, knowing that I might run into consistency problems.
My small home server is now reinstalled and instead of LVM I now use VNDs as backend storage for my Xen VMs. Also, my main filesystem with the network drives is no longer in Dom0 but is provided via Samba as DomU. So from the DomU point of view I don't have to deal with LVM any longer, instead it is a normal FFS on a block device.
Practically, to backup my DomU's I call dump from Dom0 over SSH and have the data returned to stdout so that I can save it to the USB hard drive mounted on Dom0, e.g.:
$ ssh email@example.com doas /sbin/dump -h 0 -b 64 -$NEXT_LEVEL''auf - / > $DUMP_NAME
Now I would like to ensure consistency as well and use the -X option. I have done some research on this and came across  among others. The thread is from 2010 and at that time it was exactly about how WAPBL and FSS play together. At that time probably still experimental with explicit warning in the man page. In the current NetBSD I can't find this warning anymore, which makes me hopeful. In the same thread it is also reported that it might make sense to increase the WAPBL log size to let WAPBL and FSS work together optimally. Here I would be interested once, how I come to the optimal log size? Is there a guideline or an upper/lower limit? And can someone explain me briefly how the correct function of FSS and WAPBL depend on each other? What exactly causes a too small log size?
Kind regards Matthias  https://mail-index.netbsd.org/netbsd-users/2010/05/27/msg006288.html
Description: S/MIME Cryptographic Signature