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

From: Richard Erlacher <edick_at_idcomm.com>
Date: Tue Nov 20 13:29:45 2001

It's the "quite a bit of extra work" that concerns me, as the boys at M$ haven't
managed to do it right yet, and they've been at it to the tune of 100K man hours
per year for a decade or so. Recording a bitwise image of what you receive from
the disk may or may not give you all the information you need to recreate the
files, since you may or may not know how the OS deals with them. What's more,
in order to make a complete record of the drive, you have to record every bit it
has on it and save them as a single unit, since you don't know what the drive
does with the data you send it. That's the same reason, BTW, why the drive to
which you write such an image must be an EXACT duplicate of the one from which
the image was recorded. The second drive may otherwise claim to be identical
but have a different number of sectors per physical track, use different mapping
arrangements, etc, and, especially, have different bad blocks. Since you're
going to send data that goes to where the drive sends it and not necessarily to
the same physical location from which you got it because the drive may use
different modulation, servo coding, etc, and therefore may have a different
number of sectors per track in the region of the drive to which the data is
sent, you may be disappointed with the results because IDE drives hide too many
details from the end-user.

Depending on the level of the interface you use, you may not be able to use
image recording at all. Further, if you don't know absolutely for certain, what
the drive does with the data you send it, and what the OS does to process data
to and from the drive, you're on thin ice.

I'd not recommend using image recording with a later generation IDE drive at
all. Since SCSI is well established as to how it operates its data management,
it yields more hope that you can process an image, though the vagaries of the OS
are still a limiting factor.

Image recording should work fine with MFM- and RLL-encoded drives, even on a
track-by-track basis, and those offer some hope that one could substitute one
sort of drive for another but hte ones which use BOTH CHS and LBA addressing
won't tolerate the sort of operations to which an incrementally developed OS
like Windows could create.

Dick

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


> > -----Original Message-----
> > From: Richard Erlacher [mailto:edick_at_idcomm.com]
>
> > medium, and subsequently writing them back to a physically
> > identical (not just
> > logically identical) target, without consideration for
>
> Why not just logically identical, then? ... assuming, of course, the same
> o/s would handle devices which are logically identical in an identical
> manner. (This may not be a safe assumption)
>
> [snip]
>
> > 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.
>
> I think you've just summed up my previous point. That being, of course,
> that if you can record a bit-by-bit image, you should also be able to
> interpret this image (with quite a bit of extra work), and find the
> component files. In fact, I'd add that depending on the amount of extra
> work you're willing to do, you can likely restore the image in a "logical"
> fashion to a volume that is completely different from the one on which it
> originally resided.
>
> 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 - 13:29:45 GMT