Re: bin/56643: problem with restore(8)

[Paul Goyette <paul%whooppee.com@localhost>]

The following reply was made to PR bin/56643; it has been noted by GNATS.

From: Paul Goyette <paul%whooppee.com@localhost>
To: Christos Zoulas <christos%zoulas.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: bin/56643: problem with restore(8)
Date: Mon, 24 Jan 2022 12:34:01 -0800 (PST)

 Christos Zoulas wrote:
 
 > It is still not reproducible for me:
 
 Yeah, for me using similar commands it does not fail.  (I even copied
 some files into the input file-system before dumping.)
 
 ...
 # dump -0f- /mnt | restore -rf-
    DUMP: Found /dev/rvnd0a on /mnt in mount table
    DUMP: Date of this level 0 dump: Mon Jan 24 12:12:35 2022
    DUMP: Date of last level 0 dump: the epoch
    DUMP: Dumping /dev/rvnd0a (/mnt) to standard output
    DUMP: Label: none
    DUMP: mapping (Pass I) [regular files]
    DUMP: mapping (Pass II) [directories]
    DUMP: estimated 7859 tape blocks.
    DUMP: Volume 1 started at: Mon Jan 24 12:12:40 2022
    DUMP: dumping (Pass III) [directories]
    DUMP: dumping (Pass IV) [regular files]
    DUMP: 7809 tape blocks
    DUMP: Volume 1 completed at: Mon Jan 24 12:12:40 2022
    DUMP: Date of this level 0 dump: Mon Jan 24 12:12:35 2022
    DUMP: Date this dump completed:  Mon Jan 24 12:12:40 2022
    DUMP: Average transfer rate: 0 KB/s
    DUMP: DUMP IS DONE
 #
 
 
 HOWEVER, the following sequence still fails:
 
 # dd if=/dev/zero of=TEMP bs=32k count=200000
 200000+0 records in
 200000+0 records out
 6553600000 bytes transferred in 43.794 secs (149646070 bytes/sec)
 # vnconfig -c vnd0 TEMP
 newfs -O2 vnd0a
 /dev/rvnd0a: 6250.0MB (12800000 sectors) block size 16384, fragment size 2048
          using 34 cylinder groups of 183.83MB, 11765 blks, 22848 inodes.
 super-block backups (for fsck_ffs -b #) at:
 160, 376640, 753120, 1129600, 1506080, 1882560, 2259040, 2635520, 3012000,
 ...............................................................................
 # mount /dev/vnd0a /mnt
 # cd /mnt
 # dump -0f- /var | restore -rf-
    DUMP: Found /dev/rwd0e on /var in /etc/fstab
    DUMP: Date of this level 0 dump: Mon Jan 24 12:26:14 2022
    DUMP: Date of last level 0 dump: the epoch
    DUMP: Dumping /dev/rwd0e (/var) to standard output
    DUMP: Label: none
    DUMP: mapping (Pass I) [regular files]
    DUMP: mapping (Pass II) [directories]
    DUMP: estimated 1222738 tape blocks.
    DUMP: Volume 1 started at: Mon Jan 24 12:26:16 2022
    DUMP: dumping (Pass III) [directories]
    DUMP: dumping (Pass IV) [regular files]
 getfile: lost data
 abort? [yn] n
    DUMP: 1220386 tape blocks
    DUMP: Volume 1 completed at: Mon Jan 24 12:26:48 2022
    DUMP: Volume 1 took 0:00:32
    DUMP: Volume 1 transfer rate: 38137 KB/s
    DUMP: Date of this level 0 dump: Mon Jan 24 12:26:14 2022
    DUMP: Date this dump completed:  Mon Jan 24 12:26:48 2022
    DUMP: Average transfer rate: 38137 KB/s
    DUMP: DUMP IS DONE
 #  dumpfs /var | head
 file system: /dev/rwd0e
 format  FFSv2
 endian  little-endian
 location 65536  (-b 128)
 magic   19540119        time    Mon Jan 24 12:23:54 2022
 ...
 
 Note that this time I only get thet "lost data" message once; all
 earlier occurrences had _two_ of those messages.
 
 Is there some possibility of debug-printf()s to see details of which
 input file is being processed, so we can dump the on-disk structures
 from the input volume?
 
 
 +--------------------+--------------------------+----------------------+
 | Paul Goyette       | PGP Key fingerprint:     | E-mail addresses:    |
 | (Retired)          | FA29 0E3B 35AF E8AE 6651 | paul%whooppee.com@localhost    |
 | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette%netbsd.org@localhost  |
 | & Network Engineer |                          | pgoyette99%gmail.com@localhost |
 +--------------------+--------------------------+----------------------+