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

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

Il giorno gio, 18/08/2011 alle 17.52 +0200, resoli - sourceforge ha
scritto:
> ..
> > 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.

Only to revamp the question ...
Any hint?

bye,
rob