From owner-freebsd-questions@FreeBSD.ORG Mon Nov 5 03:49:25 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8111E73 for ; Mon, 5 Nov 2012 03:49:25 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 551548FC08 for ; Mon, 5 Nov 2012 03:49:24 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 9D0DF5081B for ; Sun, 4 Nov 2012 19:49:24 -0800 (PST) To: freebsd-questions@freebsd.org Subject: Re: Questions about dump/restore to/from DVD media In-Reply-To: <20121105035233.e3c4ae8a.freebsd@edvax.de> Date: Sun, 04 Nov 2012 19:49:24 -0800 Message-ID: <22095.1352087364@tristatelogic.com> From: "Ronald F. Guilmette" X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 03:49:25 -0000 In message <20121105035233.e3c4ae8a.freebsd@edvax.de>, Polytropon wrote: >> But as I said (above) to make this really work right, dump & restore really >> need to have -z options, and do the zipping/unzipping internally. Only >> if this were available could dump properly deal with end-of-media on any >> given output volume, I think. > >The problem is that delegating compression to a "sub-task" would >imply that dump cannot precisely adjust its output to match the >media size (as the limit is now defined by how good the compression >works). Correct. We have both just said the exact same thing in different ways. In order to have _compression_ of the dump data _and_ still be able to divide the (post-compression) data into nice proper 2KB chunks (as required for DVD+/-R writing) the compression step itself would need to be integrated into the dump program itself (and then, for symmetry, if for no other reason, into restore as well). >Using dump + restore >means to operate on partitions. Make the system one partition - deal >with one partition. Make many partitions - need to deal with them >individually. Good point. >> (I hate to say it, because in general I loath & despise Windows, but even >> Windows has a built-in facility for making a single backup of an _entire_ >> system, and in a single step, *and*, I presume in a space-efficient manner.) > >That would be a task for dd. :-) Sorry? I am not following you. How could dd ever substitute for the intelligence of dump(8), and specifically how could it avoid copying of blocks that are ``in'' the filesystem but which are not currently _allocated_ by the filesystem? (I am also not persuaded the dd could handle multiple partitions any better that dump(8) currently does... which is to say not at all, really.) Regards, rfg