[Dump-users] Multivolume dump: "restore -r" fails to restore some files, but "restore -x" is fine.

[resoli - s. <re...@us...>]

Hello,
I'm using latest dump_0.4b44 (binary package from from Debian Testing);

I'm dumping a big (1.6T) and coplex (backuppc pool) UNmounted ext4
filesystem on three LTO-4 tapes,
using a custom script (-F flag) for dealing with volume swap, and
generating QFA files (-Q flag).

Dump completes without errors, but when full restoring (restore -r) some
files (usually not more than two or three) near the boundary between
second and third volume are not correctly restored: here's the log
fragment ( my comments between "*** ***" ):

========
...
*** restore invokes custom swap volume script ***
Launching /opt/comunetn/scripts/vol_start.sh
***log of custom swap volume script follows...***
2011-08-16-18:32:14 - = swap-volume: Operation vol_start volume 3 on
drive 1 =
2011-08-16-18:32:14 - Unloading volume  (EFU978L4) from drive 1
2011-08-16-18:32:14 - Scaricamento cassetta "EFU978L4" nello slot 17 ...
Unloading drive 1 into Storage Element 17...done
2011-08-16-18:33:08 - Loading volume 3 (EFU979) into drive 1
2011-08-16-18:33:09 - Caricamento cassetta "EFU979" nel drive 1 ...
Loading media from Storage Element 18 into drive 1...done
2011-08-16-18:33:21 - Waiting tape drive "/dev/nst1" to be in "BOT
ONLINE" status ...
2011-08-16-18:33:36 - OK. Drive acquired "BOT ONLINE" status in 15
seconds.
2011-08-16-18:33:36 - Setting tape drive options ... 
Trying to open database '/etc/stinit.def'.
Open succeeded.
Mode 1 definition: scsi2logical=1  can-bsr drive-buffering
can-partitions auto-lock buffer-writes=0 async-writes=0 read-ahead
timeout=800 long-timeout=14400  blocksize=1024k density=0x00
compression=0 

stinit, processing tape 1
Mode 1, name '/dev/nst1'
Mode 2, name '/dev/nst1l'
Mode 3, name '/dev/nst1m'
Mode 4, name '/dev/nst1a'
The manufacturer is 'HP', product is 'Ultrium 4-SCSI', and revision
'B45W'.
2011-08-16-18:33:36 - Drive "/dev/nst1" status follows:
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 1048576 bytes. Density code 0x46 (LTO-4).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN
***end of custom swap volume script log***
Incorrect block for <file1 path> at 1588999555 blocks
Incorrect block for <file1 path> at 1588999556 blocks
*** so on for same file1 on many consecutive blocks ***
Incorrect block for <file1 path> at 1589000042 blocks
Missing blocks at the end of <file1 path>, assuming hole
<file2 path>: (inode 122169539) not found on tape
<file3 path>: (inode 122169540) not found on tape
...
========

To my surprise, "restore -x -a -Q" , using the genereted QFA file,
correctly restores these three files without problems from third volume,
swapping directly from first to third volume.

I post here also the relevant fragment of QFA file, near the boundary
between second and third volume:

========
...
122169536       2       775829
122169537       2       775831
122169537       3       1
122169539       3       3
122169540       3       5
122169541       3       7
122169543       3       8
...
========

My guess is (i'm not confident enough with restore code to verify this
directly) that there is some incongruence in restore behavior between
"-r" and "-x" modes.

Thanks,
Roberto Resoli