Re: dump problems

> On Tue, Sep 04, 2007 at 09:47:16PM +0300, Danny Braniss wrote:
> > > On Tue, 2007-09-04 at 18:51 +0300, Danny Braniss wrote:
> > > > dump start out nicely, but then it justs hangs.
> > > > have tried it with different file systems, the output
> > > > is also a file, again tried it with different file system.
> > > > the only way it works is if the output file is /dev/null (very
> > > > fast, but not realy helpful :-)
> > > 
> > > When it hangs, what is printed when you send it a CTRL-T?
> > > 
> > off the top of my head:
> > 
> > ... running ...
> > 
> > it seems to be a problem on the writing side, since setting the output
> > to /dev/null actually works.
> > 
> > the commands used were:
> > 
> > dump 0Lf - /some/file/system | restore rf -
> > this got stuck, so I started experimenting:
> > dump 0Lf file.dump  /some/file/system
> > 
> > gets stuck, ^T will mostly return ... [running] ... since at least
> > one of the dump process is running, but my guess it's just monitoring.
> > I also tried without the L flag, but did not change the result.
> > the only dump that finishes, is when the output is /dev/null.
> 
> Try again with the 'a' flag. dump(8) still assumes that it writes
> to a set of tapes, and if the writing stalls for some reason (restore(8)
> being slow or somesuch), dump may ask to switch tapes. Since all this
> is of course bogus now, use 'a' to disable all those tape size
> calculation heuristics, as in
> 
> # dump 0Luaf - /some/file/system | restore rf -
true, but
	1- if output is stdout it does not do any tape size calculations
	2- it does not differentiate between 'regular file' and 'special file'
	   and thus will stop requesting for another tape.
so, yes, i forgot to say that i did use the -a flag, but i did say it's stuck,
not that it's waiting for any tape change.

so, sorry, no cookies yet :-)

danny