From owner-freebsd-questions@FreeBSD.ORG Mon Nov 5 04:14:56 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 023EB31E for ; Mon, 5 Nov 2012 04:14:56 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mx1.freebsd.org (Postfix) with ESMTP id B321A8FC08 for ; Mon, 5 Nov 2012 04:14:55 +0000 (UTC) Received: from r56.edvax.de (port-92-195-8-72.dynamic.qsc.de [92.195.8.72]) by mx01.qsc.de (Postfix) with ESMTP id 295C73CA2D; Mon, 5 Nov 2012 05:14:48 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id qA54El5U002945; Mon, 5 Nov 2012 05:14:47 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Mon, 5 Nov 2012 05:14:47 +0100 From: Polytropon To: "Ronald F. Guilmette" Subject: Re: Questions about dump/restore to/from DVD media Message-Id: <20121105051447.6eef32ef.freebsd@edvax.de> In-Reply-To: <22095.1352087364@tristatelogic.com> References: <20121105035233.e3c4ae8a.freebsd@edvax.de> <22095.1352087364@tristatelogic.com> Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 04:14:56 -0000 On Sun, 04 Nov 2012 19:49:24 -0800, Ronald F. Guilmette wrote: > > 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). Chunk size _and_ media size matter (as dump would have to "know" when the media is expected to be "nearly-full" _with_ compression) because the operator will be required to deal with multi-volume media ("next DVD"). > >> (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? It cannot. :-) With dd, you could copy a disk including all aspects of the present slices and partitions (including file attributes and partitioning data, even boot elements), but it would maybe require a subsequent "read and compare" step to make sure that everything went well. > (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.) It can - depending on what device you're reading from. Examples: dd if=/dev/ad0s1a -> the root partition dd if=/dev/ad0s1 -> the 1st slice dd if=/dev/ad0 -> the whole disk However, dd is very much "bare metal" and cannot handle multiple volumes and compression natively. It would be neccessary to have all those functionalities scripted additionally. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...