From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 23:47:47 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 42D5C16A417; Tue, 4 Sep 2007 23:47:47 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id D21D613C461; Tue, 4 Sep 2007 23:47:46 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from epia-2.farid-hajji.net (epia-2 [192.168.254.11]) by fw.farid-hajji.net (Postfix) with ESMTP id 0CA6DDF141; Wed, 5 Sep 2007 01:31:06 +0200 (CEST) Date: Wed, 5 Sep 2007 01:32:46 +0200 From: cpghost To: Danny Braniss Message-ID: <20070904233246.GA2409@epia-2.farid-hajji.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) 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: Tue, 04 Sep 2007 23:47:47 -0000 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 - > danny Good luck, -cpghost. -- Cordula's Web. http://www.cordula.ws/