From owner-freebsd-fs@FreeBSD.ORG Wed Mar 25 01:19:05 2009 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BF23106566C; Wed, 25 Mar 2009 01:19:05 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.freebsd.org (Postfix) with ESMTP id 848C88FC1D; Wed, 25 Mar 2009 01:19:04 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.14.3/8.14.3) with ESMTP id n2P1IuY9071528; Tue, 24 Mar 2009 21:19:01 -0400 (EDT) (envelope-from mi+thun@aldan.algebra.com) Message-ID: <49C98680.7020301@aldan.algebra.com> Date: Tue, 24 Mar 2009 21:18:56 -0400 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.18 (X11/20081126) MIME-Version: 1.0 To: Andrew Snow References: <49C83673.3000604@aldan.algebra.com> <200903241537.36515.doconnor@gsoft.com.au> <49C87E0D.5090501@aldan.algebra.com> <49C90813.8070705@aldan.algebra.com> <49C98202.9040403@modulus.org> In-Reply-To: <49C98202.9040403@modulus.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org, fs@freebsd.org Subject: Re: dump | restore fails: unknown tape header type 1853384566 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 01:19:06 -0000 Andrew Snow ΞΑΠΙΣΑΧ(ΜΑ): > Mikhail T. wrote: >> dump 0aCf 64 /ibm/ibmo.0.2009-03-24.dump /old >> DUMP: WARNING: should use -L when dumping live read-write >> filesystems! > > I thought you said it was a read-only filesystem? It was yesterday. Today I remounted it rw to remove some junk-files, which I don't need to transfer. I don't believe, this is causing the problems. > In my experience, restore can sometimes throw warnings if you dump a > live filesystem. It might be causing your errors? If possible, can > you try completely unmounting the filesystem you are dumping and > trying again? I don't think, restore can even figure this out, much less throw a warning -- it is dump, that complains... But the dump started this morning is still hanging (in sbwait) -- I've never seen this before. I'm also very troubled, that such an important functionality (dump/restore!) is sooo problem-prone, and yet so few people seem to care... Is the official view, that dump is obsolete (and already bit-rotten), perhaps, and use of tar is encouraged instead? -mi