strange behavior of restore(8)

[Victor Sudakov]

Matthias Apitz wrote:
> > Victor Sudakov 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.

How many files did your 130G filesystem have? My 51G dump
should contain 1769484 files in 24705 directories.

> > > > 
> > > > 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?

Lo and behold! On an amd64 system with 8GB RAM and 2 2.66GHz Xeon
CPUs, "restore -rNf home.dmp" has successfully completed after 3 hours
15 minutes.

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