Date: Mon, 5 Nov 2012 05:14:47 +0100 From: Polytropon <freebsd@edvax.de> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-questions@freebsd.org 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 04 Nov 2012 19:49:24 -0800, Ronald F. Guilmette wrote:
>
> In message <20121105035233.e3c4ae8a.freebsd@edvax.de>,
> Polytropon <freebsd@edvax.de> 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, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121105051447.6eef32ef.freebsd>