From owner-freebsd-current@FreeBSD.ORG Wed Sep 5 05:46:44 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 049A816A418; Wed, 5 Sep 2007 05:46:44 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id B014313C459; Wed, 5 Sep 2007 05:46:43 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1ISnig-000Nbm-Ep; Wed, 05 Sep 2007 08:46:30 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: cpghost In-reply-to: <20070904233246.GA2409@epia-2.farid-hajji.net> References: <20070904233246.GA2409@epia-2.farid-hajji.net> Comments: In-reply-to cpghost message dated "Wed, 05 Sep 2007 01:32:46 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Sep 2007 08:46:30 +0300 From: Danny Braniss Message-ID: 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: Wed, 05 Sep 2007 05:46:44 -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 - 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