From owner-freebsd-current@FreeBSD.ORG Sat Sep 8 10:26:05 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D63516A41B for ; Sat, 8 Sep 2007 10:26:05 +0000 (UTC) (envelope-from bsd-current@epcdirect.co.uk) Received: from gunfright.epcdirect.co.uk (gunfright.epcdirect.co.uk [195.10.242.32]) by mx1.freebsd.org (Postfix) with ESMTP id DF68413C45D for ; Sat, 8 Sep 2007 10:26:04 +0000 (UTC) (envelope-from bsd-current@epcdirect.co.uk) Received: from localhost (localhost.epcdirect.co.uk [127.0.0.1]) by gunfright.epcdirect.co.uk (Postfix) with ESMTP id E4BF76176; Sat, 8 Sep 2007 11:26:03 +0100 (BST) X-Virus-Scanned: by GunFright.EPCDirect.co.uk Received: from gunfright.epcdirect.co.uk ([127.0.0.1]) by localhost (gunfright.epcdirect.co.uk [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id X+iAUJNBEjTC; Sat, 8 Sep 2007 11:26:03 +0100 (BST) Received: from lfarr (lfarr.adsl.gemsoft.co.uk [195.10.239.114]) by gunfright.epcdirect.co.uk (Postfix) with ESMTP id 560346128; Sat, 8 Sep 2007 11:26:03 +0100 (BST) From: "Lawrence Farr" To: "'Danny Braniss'" , "'cpghost'" References: <20070904233246.GA2409@epia-2.farid-hajji.net> In-Reply-To: Date: Sat, 8 Sep 2007 11:26:01 +0100 Message-ID: <043a01c7f202$a7ad0920$f7071b60$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcfvgFXwJTQl7kvVQ0CjruOoG1yfPgCgbqFw Content-Language: en-gb Cc: freebsd-current@FreeBSD.org, 'Gavin Atkinson' Subject: RE: dump problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2007 10:26:05 -0000 > -----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?