kern/57475: Error message ffs_snapshot_mount: vget failed 2 after fsck

[mp%petermann-it.de@localhost]

>Number:         57475
>Category:       kern
>Synopsis:       Error message ffs_snapshot_mount: vget failed 2 after fsck
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jun 20 05:40:00 +0000 2023
>Originator:     Matthias Petermann
>Release:        10.0_BETA
>Organization:
>Environment:
etBSD vhost2.lan 10.0_BETA NetBSD 10.0_BETA (XEN3_DOM0) #0: Sun Jun 11 22:32:13 UTC 2023  root@ws.local:/build/netbsd-10/obj/sys/arch/amd64/compile/XEN3_DOM0 amd64
>Description:
I have used fssconfig to create a persistent snapshot on /data/.snap
created. Afterwards several actions caused a crash of the
system crash. I then performed an fsck, which removed the file
among other things the file /data/.snap was removed. Since then
when mounting the file system the message:

[ 12.132674] ffs_snapshot_mount: vget failed 2

The message seems to be originated from sys/ufs/ffs/ffs_snapshot.c,
when a snapshot is registered in the superblock and the corresponding
inode no longer exists.

However, with fsdb the file ".snap" with type unknown is still 
found:

vhost2$ doas fsdb -n /dev/rdk3
** /dev/rdk3 (NO WRITE)
** File system is journaled; replaying journal
CANNOT REPLAY JOURNAL IN -n MODE; continuing anyway
Editing file system `/dev/rdk3'
Last Mounted on /data
current inode: directory
I=2 MODE=40755 SIZE=512 EXTSIZE=0
            MTIME=Jun 19 18:01:25 2023 [707192237 nsec]
            CTIME=Jun 19 18:01:25 2023 [707192237 nsec]
            ATIME=Jun 20 04:15:14 2023 [239283678 nsec]
        BIRTHTIME=Jun 14 09:44:25 2023 [727546000 nsec]
OWNER=root GRP=wheel LINKCNT=4 FLAGS=0x0 BLKCNT=0x8 GEN=0x4a3fafc8
fsdb (inum: 2)> ls
slot 0 off 0 ino 2 reclen 12: directory, `.'
slot 1 off 12 ino 2 reclen 12: directory, `..'
slot 2 off 24 ino 26797056 reclen 20: directory, `prometheus'
slot 3 off 44 ino 36166656 reclen 12: directory, `vhd'
slot 4 off 56 ino 0 reclen 456: unknown, `.snap'
fsdb (inum: 2)>

Beside the actual bug report, actually there are two points I'd like to ask for help:

- What can I do to get rid of the "unknown" .snap entry in the root directory
of the FS without damaging the Filesystem?

- How can I unregister the snapshot from the superblock to get gid of the vget vailed 2
message?
>How-To-Repeat:
Not sure if all of this contributes to the actual problem, but here is the bigger picture:

1) Setup a FFSv2 with WAPBL (/data)
2) Create some sparse deployed vnd-images (/data/vhd1.img, /data/vhd2.img ...) 
3) configure the vnd-images so that they become available as vnd1....vndX (implicitly by Xen Dom0 xbd backend)
4) format the vnd images with FFSv2 and WAPBL (within Xen DomU)
5) create a persistent snapshot of /data as /data/.snap (fss0)
6) mount the snapshot read-only to /mnt
7) configure the vnd-images from the snapshot under/tmp/vhd1.img, /tmp/vhd2.img ... so they become vndX+1, vndX+2 ...
8) use /sbin/dump to dump the filesystems from vndX+1, vndX+2 

While dump is running, the system crashes. After booting into single user mode and doing fsck_ffs, the filesystem can be recovered. At this point /data/.snap gets unlinked by fsck. At the next boot, the "vget failed 2" message occurs in the kernel log.
>Fix:
n/a