RE: dump problems

> -----Original Message-----
> From: owner-freebsd-current_at_freebsd.org [mailto:owner-freebsd-
> current_at_freebsd.org] On Behalf Of Danny Braniss
> Sent: 05 September 2007 06:47
> To: cpghost
> Cc: freebsd-current_at_FreeBSD.org; Gavin Atkinson
> Subject: 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
> 


I'm running my dumps from a periodic script, and it's been sat like this
since last night:

    0 30447 30374   0   8  0 28240 25964 wait   S     ??    0:00.20 dump
-1auf /mnt/dump/epcduk1/da0s1f.1.dmp /dev/da0s1f (dump)
    0 30448 30447   0   4  0 28240 25988 sbwait S     ??    0:00.87 dump:
/dev/da0s1f: pass 4: 0.08% done, finished in 13:35 at Sat Sep  8 14:37:36
2007 (dump)
    0 30449 30448   0  20  0 28240 25964 pause  S     ??    0:00.99 dump
-1auf /mnt/dump/epcduk1/da0s1f.1.dmp /dev/da0s1f (dump)
    0 30450 30448   0  20  0 28240 25964 pause  S     ??    0:01.00 dump
-1auf /mnt/dump/epcduk1/da0s1f.1.dmp /dev/da0s1f (dump)
    0 30451 30448   0  20  0 28240 25964 pause  S     ??    0:01.00 dump
-1auf /mnt/dump/epcduk1/da0s1f.1.dmp /dev/da0s1f (dump)

Is there any way of working out what's happening to these?