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

From: Christopher Smith <csmith_at_amdocs.com>
Date: Tue Nov 20 14:28:18 2001

> -----Original Message-----
> From: Richard Erlacher [mailto:edick_at_idcomm.com]

> 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

Well, I haven't got much faith in them to begin with. They could work for
1000 years on a 20 minute job and still mess it up. I'm not saying that it
might not actually take that long, just that m$ aren't competent enough to
be a good indicator.

> 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,

I was assuming you'd know the filesystem type at the time of the backup. I
don't suppose it would be absolutely necessary. You might also recognize a
filesystem by magic number/signature, or the like.

[snip]

> 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

Well, "otherwise identical" is dangerous territory at any rate. :) You're
right, though, in that depending on the way the software components interact
with the drive, one or more of these things might really screw things up. I
suppose that would require one to know the internals of each system with
which you plan to use this method.

> 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

... which may be ok, depending on how the system interacts with the device
in question. Of course, if you find that the system depends on the data
being in some physical location, rather than in a logical location, you'd
have to correct for that or _just not do it_ ;)

[snip]

> sent, you may be disappointed with the results because IDE
> drives hide too many
> details from the end-user.

Yep. Tell me about it.

[snip]

> 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.

That depends. For instance (This will now get very hypothetical), if the
O/S handles data in logical blocks, and doesn't care too much the actual
geometry of the drive, you might be ok with not knowing about the device.
That is, with the exception of bad blocks. (Really I guess I'm talking
about faking a standard interface even when it doesn't exist here)

[snip]

> 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.

On the other hand, as some friends of mine are wont to say: "Neither S in
SCSI means standard."

> 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.

Can't argue with that.

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 - 14:28:18 GMT