20 Nov
2001
20 Nov
'01
2:18 a.m.
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(a)amdocs.com>
To: <classiccmp(a)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@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");
'