[TUHS] v6tar from v7 on v6, too large?

[cubexyz@gmail.com (Mark Longridge)]

Ok, I can make a few remarks about v6tar and ar and dd.

I've never been able to transfer any file larger than 64K to Unix V5 or V6.
Smaller than 64K seems to work fine. I'm using the same command on V5 and V6:

dd if=/dev/mt0 of=cont.a bs=1 count=90212

And I'll get:

24676+0 records in
24676+0 records out

Now, if we take 90212 and subtract 65536 we get 24676 bytes. So there
definitely seems to be some 64K limit here and I don't think it's just
a v6tar limitation.

I compiled the kernel with m45.s on V6 and mch.s on V5. I also don't
recall seeing any file on V5 or V6 larger than 65536 bytes, but it's
possible I've overlooked one.

My workaround solution was to simply keep tar files and archive files
under 64K but I would be interested to hear of a better solution.

Mark


On 12/9/15, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>     > From: Noel Chiappa
>
>     > the most likely is that 'v6tar' is linked to be split I+D, and your
> V6
>     > emulation is on a machine that doesn't have split I+D (e.g. an 11/40)
>
> Now that I think about it, the linked systems that are part of the V6
> distro
> tape are all linked to run on an 11/40. They will boot and run OK on a more
> powerful machine (/45 or /70), but they will act like they are on a /40 -
> i.e. no split I+D support/use (user or kernel). So to get split I+D
> support,
> you need to build a new Unix binary, with m45.s instead of m40.s. If you
> haven't done that, that's probably what the problem is.
>
>
> Aside: V6 comes in two flavours: no split I+D at all, or split I+D in both
> the kernel and user. For some reason that I can't recall, we actually
> produced an 'm43.s', BITD at MIT, which ran the kernel in non-split-I-D,
> but
> supported split I-D for the users.
>
> I wish I could remember why we did this - it couldn't have been to save
> memory (the machine didn't have a great deal on it when this was done -
> although I have this vague memory that that was why we did it), because
> running split I+D in the kernel does not, I think, use any more physical
> memory (provided you don't fiddle with the parameters like the number of
> buffers) than running non-split. Or maybe it does?
>
> One possible reason was that the odd layout of memory with split I+D in the
> kernel made debugging kernel code harder (we were doing a lot of kernel
> hacking to support early networking work); another was that we were just
> being
> conservative, didn't need to extra space in the kernel that I+D allowed,
> and
> so didn't want to run it.
>
> 	Noel
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>