strange behavior of restore(8)

[Victor Sudakov]

Matthias Apitz wrote:
> 
> > > > >
> > > > > I am trying to restore a UFS2 zero level dump sized about 51G.
> > > > > restore has created 6105 directories and no files at all, and now is
> > > > > waiting forever in the runnable state.
> 
> Side note: I have already restored UFS level zero dumps of 130G, even
> into FreeBSD in a VM, without any kind of problem. Don't know UFS2,
> though.
> 
> > > > 
> > > > I don't have any specific advice here, but if it were me I think my
> > > > next troubleshooting step would be to attach truss to the restore
> > > > process after it gets "stuck," to try to see exactly what it's doing.
> > > > That may give you a clue as to why it's taking so long and whether
> > > > it's actually making any progress.
> > > 
> > > It's doing something like that. I should have piped the output
> > > through uniq not to clutter the list, but on second thought, I decided
> > > not to:
> > > 
> > > # truss -p 18568
> > > lseek(4,0x0,SEEK_CUR)				 = 25395100 (0x1837f9c)
> > > lseek(4,0x0,SEEK_CUR)				 = 25395100 (0x1837f9c)
> > > lseek(4,0x0,SEEK_CUR)				 = 25395100 (0x1837f9c)
> > > lseek(4,0x0,SEEK_CUR)				 = 25395100 (0x1837f9c)
> 
> Asuming 4 is the fd of the restore device, i.e. the DUMP, this seek does
> nothing: moves to offset of 0 bytes from the current position. Are you
> sure that the device (tape?) is fine?

I have already copied the dump from tape to disk with dd and tried restoring
from the disk file with the same effect.

The disk is fine in the sense that the dump file can be copied from
tape to disk and from disk to /dev/null without any errors.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:sudakov at sibptus.tomsk.ru