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

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

..
> 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
> ...
> ========

I forgot to add the log fragment from dump:

==========
...
  DUMP: Volume 3 started with block 1588986880 at: Tue Aug 16 10:07:05
2011
  DUMP: Volume 3 begins with blocks from inode 122169536
...
==========

It seems that informations from dump log are not congruent with QFA
ones: dump log says that part of inode 122169536 is on volume 3, QFA
records his position only on volume 2.

bye,
Roberto Resoli