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

From: Richard Erlacher <edick_at_idcomm.com>
Date: Mon Nov 19 19:07:43 2001

If you're meaning operating on the tape contents, you're talking about weeks to
months. The bits of a file are scattered around the disk, since it's random
access, albeit in "clusters" or whatever you choose to call them, and in blocks,
as the data buffer stores them, but unless you KNOW where the directory is in
the bitwise image of the disk, and unless you know where all the pieces of the
drive are to be found in the tape image, I'd submit it would be a mite tedious.
The problem, of course, with image backup, is that the bits have to be extracted
from the drive at the raw data level, i.e. with controller commands you normally
don't deal with, and they can't be faithfully restored to a drive that's not
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.

Remember, when you restart the system, it has no OS other than what you can load
from a floppy. IF that's the same, which certainly isn't the case under
WIndows, as what you used to do the backup, then you're able, 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.

Dick

----- Original Message -----
From: "Christopher Smith" <csmith_at_amdocs.com>
To: <classiccmp_at_classiccmp.org>
Sent: Monday, November 19, 2001 4:00 PM
Subject: RE: OT: paging MAC expert(s) --- What's a Performa?


> > -----Original Message-----
> > From: Richard Erlacher [mailto:edick_at_idcomm.com]
>
> > If your recorded "backup" is a bit-for-bit image of the disk contents,
> > transferred to and from tape, there's no interpretation of
> > the contents into
> > files that can take place, is there?
>
> That's an interesting way to phrase this particular question, since the
> contents are already in the form of "files" -- that is, if you ask the set
> of drivers that got them to the disk in the first place. :)
>
> I believe it's possible (though it would be slow) to interpret a bit-for-bit
> image directly on a tape and extract any given file, along with attributes,
> etc. In fact, any operation that would be possible on a disk, in this case,
> could be handled on a tape. The clincher is that it would involve a lot of
> seek/rewind/seek/etc/etc..
>
> The underlying O/S need not even know the difference between the disk and
> tape, except to know that the tape is removable (...that's not absolutely
> required), and perhaps that it's incredibly slow.
>
> The worst that would be required is a device abstraction layer or the like.
> You could write one yourself which would make the tape device "look" like a
> disk device, for systems which don't have such a thing, and that would be
> enough.
>
> How would you like to be able to mount your backup tape, and use a
> file-manager on it? ;)
>
> > The Microsoft Backup that came with DOS, (a) never really was
> > a backup, but,
> > rather, was just a copy, and (b) never worked together with
> > its "restore"
> > function. Under DOS, copies were adequate, since the context
> > didn't matter.
>
> If you mean that it didn't store attributes, or that sort of thing, you may
> be right (never paid attention.) On the other hand, you're also right to
> say that it wouldn't particularly matter under MS-DOS.
>
> 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 Mon Nov 19 2001 - 19:07:43 GMT

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