kern/55362: bad inodes created after dump|restore

[prlw1%cam.ac.uk@localhost]

>Number:         55362
>Category:       kern
>Synopsis:       bad inodes created after dump|restore
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jun 10 13:25:00 +0000 2020
>Originator:     Patrick Welche
>Release:        NetBSD-9.99.65/amd64
>Organization:
>Environment:
-current of 9 June 2020, 8:07 UTC
>Description:
In brief dump | restore creates something which is unusable. Better to describe as the steps to reproduce to avoid semantic meanings of "filesystem" or "partition".

dk20 at cgd0: "oldbackup", 7814057728 blocks at 128, type: ffs
dk21 at cgd1: "backup", 12884901600 blocks at 40, type: ffs

Both are on raidframe, it so happens that "oldbackup" is raid 5, whereas "backup" is on raid1. Both are ffs v2.

fsck -f /dev/rdk20           all OK
mount name=oldbackup /store/raid5
newfs -O2 /dev/rdk21
mount -o async name=backup /store/backup   (same happened earlier without async)
cd /store/backup
dump -0uaXf - /store/raid5 | restore rf -

  DUMP: 61.44% done, finished in 7:52
  DUMP: 3481184598 tape blocks
  DUMP: Volume 1 completed at: Wed Jun 10 08:12:00 2020
  DUMP: Volume 1 took 20:38:21
  DUMP: Volume 1 transfer rate: 46852 KB/s
  DUMP: Date of this level 0 dump: Tue Jun  9 11:33:05 2020
  DUMP: Date this dump completed:  Wed Jun 10 08:12:00 2020
  DUMP: Average transfer rate: 46852 KB/s
  DUMP: level 0 dump on Tue Jun  9 11:33:05 2020
  DUMP: DUMP IS DONE
# cd ..
# umount /store/backup
# fsck /dev/rdk21
** /dev/rdk21
** File system is clean; not checking
quantz# fsck -f /dev/rdk21
** /dev/rdk21
** File system is already clean
** Last Mounted on /store/backup
** Phase 1 - Check Blocks and Sizes
PARTIALLY TRUNCATED INODE I=187721310
SALVAGE? [yn] n

-3806487682048676796 BAD I=187721310
-8054706583720281705 BAD I=187721310
-2116918007204608326 BAD I=187721310
4171795335284772382 BAD I=187721310
-6832354079944068152 BAD I=187721310
-5029522714663959145 BAD I=187721310
101993166284650241 BAD I=187721310
-3217679531023626255 BAD I=187721310
-1789572272864921531 BAD I=187721310
6627881258759745910 BAD I=187721310
4268130136434363919 BAD I=187721310
EXCESSIVE BAD BLKS I=187721310
CONTINUE? [yn] n


This is the second time around for me. I first mentioned it at:
http://mail-index.netbsd.org/current-users/2020/06/07/msg038814.html
I note that this looks similar:
http://mail-index.netbsd.org/netbsd-users/2020/05/28/msg024985.html
so probably not a local problem.

Not sure if relevant, but on the 2 disks which form the mirror "backup" is on, there is also a zfs pool of 2 pieces of those disks. Doing a similar dump | restore of 2.2T to the zfs partition, zfs scrub is happy afterwards. I assume that is the equivalent of fsck.
>How-To-Repeat:

>Fix: