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

the only indication I can see, is that one of the dump procs. is waiting on
sbwait, and probably it's some deadlock, which is similar to what I keep
seeing here, i'll try now with SCHED_ULE to see if it make a difference.

danny