OT: paging MAC expert(s) --- What's a Performa?

From: Richard Erlacher <edick_at_idcomm.com>
Date: Tue Nov 20 10:18:14 2001

Perhaps you've lost track, but the subject was recording a bitwise image of the
drive to be restored, rather than a file-by-file image. This involves taking
raw blocks of data, in some repeatable sequence, saving them on a storage
medium, and subsequently writing them back to a physically identical (not just
logically identical) target, without consideration for whether the data in a
given block is part of a file or part of a directory (also a file, but who
cares?), the object being to recreate the original environment.

An example might be recording the "container file" in a compressed volume. Much
of that file might be unallocated space, but, as the file is, itself, allocated
in the uncompressed domain, restoring it bitwise will restore the compressed
partition and its associated file system. One can also record the file data
under an operating system that recognizes the compressed partition, the result
of which would be the recording of the uncompressed data.

The bitwise image transfer from disk=>tape can be done without knowledge of
either the compression scheme or of the OS/file system used on it. It does
require, however, that the entire image be recorded so it can be restored in its
entirety. The result is that you can use a different OS to do that task though
it's not required, and the penalty is that you have no access to the file data,
though you could, I guess, go to the trouble of deciphering the bitwise image
into a logical file system if one originally existed. You can do that under any
circumstances, but it's a lot of trouble and requires you know a great deal
about the low-level processes of converting the data on the orginal drive into
the files comprising it.

Dick

----- Original Message -----
From: "Christopher Smith" <csmith_at_amdocs.com>
To: <classiccmp_at_classiccmp.org>
Sent: Tuesday, November 20, 2001 8:23 AM
Subject: RE: OT: paging MAC expert(s) --- What's a Performa?


> > -----Original Message-----
> > From: Richard Erlacher [mailto:edick_at_idcomm.com]
>
> > drive are to be found in the tape image, I'd submit it would
> > be a mite tedious.
>
> Well, I didn't say it would be easy ;) It's one of those things that is
> theoretically simple.
>
> > physically identical to the one you started with, i.e. same
> > number of heads,
> > cylinders, sectors, etc, PHYSICALLY, else things fall apart,
> > since we don't know
> > how the drive firmware deals with translating from the
> > block-level commands the
> > OS may choose to send it, though it doesn't have to, to the
> > buffers-full of data
> > that the drive coughs up.
>
> There must be a method of block-by-block access that will give you the
> sequence of data you need. Otherwise things would have already fallen
> apart, and disks would be write-only devices. :) It probably helps to think
> of the filesystem as a data set, rather than a device-dependant entity. The
> data is the same, up to a point, no matter what you write it to.
>
> Of course, whether the amount of translation you'd need to do to find that
> essential data set is too much work, is arguable....
>
> > potentially, to
> > deal with the data to be transferred to the newly cleaned
> > drive in the same way
> > that this particular OS deals with it. Of course, the OS
> > doesn't know what
> > you're doing, and doesn't know how to read the data on the
> > disk, except as raw
> > data, dealt with in buffer-fulls, and than only using the
> > code you've written.
>
> I'm not sure I follow your train of thought here. It's early, though.
>
> Regards,
>
> Chris
>
>
> Christopher Smith, Perl Developer
> Amdocs - Champaign, IL
>
> /usr/bin/perl -e '
> print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");
> '
>
>
>
Received on Tue Nov 20 2001 - 10:18:14 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:34:12 BST