Date: Sat, 8 Sep 2007 11:26:01 +0100 From: "Lawrence Farr" <bsd-current@epcdirect.co.uk> To: "'Danny Braniss'" <danny@cs.huji.ac.il>, "'cpghost'" <cpghost@cordula.ws> Cc: freebsd-current@FreeBSD.org, 'Gavin Atkinson' <gavin@FreeBSD.org> Subject: RE: dump problems Message-ID: <043a01c7f202$a7ad0920$f7071b60$@co.uk> In-Reply-To: <E1ISnig-000Nbm-Ep@cs1.cs.huji.ac.il> References: <E1ISdQi-000GkC-4v@cs1.cs.huji.ac.il> <20070904233246.GA2409@epia-2.farid-hajji.net> <E1ISnig-000Nbm-Ep@cs1.cs.huji.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message-----
> From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-
> current@freebsd.org] On Behalf Of Danny Braniss
> Sent: 05 September 2007 06:47
> To: cpghost
> Cc: freebsd-current@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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?043a01c7f202$a7ad0920$f7071b60$>