From owner-freebsd-current@FreeBSD.ORG Thu Oct 18 11:35:13 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 8FC9516A418 for ; Thu, 18 Oct 2007 11:35:13 +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 4C25413C457 for ; Thu, 18 Oct 2007 11:35:12 +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 1IiTeh-0007tt-G6; Thu, 18 Oct 2007 13:35:11 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: hackers@FreeBSD.org In-reply-to: References: <20070904233246.GA2409@epia-2.farid-hajji.net> <043a01c7f202$a7ad0920$f7071b60$@co.uk> <046801c7f229$a4534510$ecf9cf30$@co.uk> Comments: In-reply-to Danny Braniss message dated "Mon, 10 Sep 2007 11:14:45 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Oct 2007 13:35:11 +0200 From: Danny Braniss Message-ID: Cc: freebsd-current@FreeBSD.org 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: Thu, 18 Oct 2007 11:35:13 -0000 > > > > > > > > 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. > > > > > > > > > I'm running SCHED_ULE on these already, if your not I guess it's not the > > > scheduler? > > > > > I can get it to 'work' by fiddling with the b flag (blocksize), which still > > points to some timming/deadlock problem. > > ie: > > dump 0abf 64 /some/backup/file /file/to/backup > > now works, but > > dump 0abf 64 - | restore rbf 64 - > > hangs as before. (i don't think the b 64 in restore is needed). > > ok, it is time to look at the sources, this program has been around since the > beginin of time, > or at least since Unix V6 :-), and it has been hacked ever since. but now that > most of you never heard of 9track tapes, etc, I was wondering if there is a > point in hacking at > it again. > pros: dump/restore has never failed me till now. > cons: there are other programs tar/cpio/gtar/etc, but they each have their > nits. > so here are some questions: > - is the readers/writer split realy needed now? my guess it was put in in the > old > days to get tapes streaming - which is btw, what's not working. > - is it/will it be needed for ZFS? [dump is for ufs ...] > > danny Assumption: Since dump was written, much has changed, and in the days of single-core/UP the Caltech hack (see /usr/src/sbin/dump/tape.c) works. On newer multicore hardware it will enter into deadlock and thus hang, specially if 'tape' is a file or pipe. While I'm now putting on the surgical cap to dissect tape.c, any further insight is welcome. cheers, danny