[TUHS] unix v5 limitations

[TUHS] unix v5 limitations

[Mark Longridge]

Firstly, I should mention I'm using simh to simulate Unix version 5.

Well I tried to reorganize the files in unix v5. Mainly I wanted more
room on rk0 so I figured I'd create a new drive and put all the source
from /usr/source/s1 on it.

The first problem I had was I couldn't just cp over all the
/usr/source/s1 files to the new drive because of "Arg list too long"
so I figured I would just create an archive file called all.a which
would include all the files in /usr/source/s1 and copy that over.

But then I got "phase error" when I tried to keep adding files to the
archive (I had to do this in stages, e.g. ar r all.a /usr/source/s1/a*
then ar u all.a /usr/source/s1/b* etc). Phase error seemed to occur
when the archive got larger than around 160,000 bytes. So I ended up
creating 3 archive files to keep from getting "phase error".

I was wondering does anyone understand what the limits are for the cp
and ar commands?

Mark

[TUHS] unix v5 limitations

[John Cowan]

Mark Longridge scripsit:

> The first problem I had was I couldn't just cp over all the
> /usr/source/s1 files to the new drive because of "Arg list too long"
> so I figured I would just create an archive file called all.a which
> would include all the files in /usr/source/s1 and copy that over.

That is not a cp error: it is the kernel reporting that the limited
amount of space in userland reserved for command arguments on an exec()
has been exceeded.  It can still happen in modern systems if directories
are exceedingly large.

> But then I got "phase error" when I tried to keep adding files to the
> archive 

"Phase error" means that a file has been modified while "ar" is working
on it.  The most common reason (which doesn't seem to be relevant in
this case) is that "ar" is trying to archive the archive.

> ar u all.a /usr/source/s1/b*

If that worked, then "cp /usr/source/s1/b* ." would work too.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
I am expressing my opinion.  When my honorable and gallant friend is
called, he will express his opinion.  This is the process which we
call Debate.                   --Winston Churchill

[TUHS] unix v5 limitations

[Sven Mascheck]

On Sat, Aug 09, 2014 at 11:32:02AM -0400, Noel Chiappa wrote:
> John Cowan nailed this; as an aside, I don't know about V5, but in vanilla V6
> the entire argument list had to fit into one disk buffer (I would assume V5 is
> the same).

V4 to V6 had this limit of 512 bytes. It's documented in exec(2),
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/man/man2/exec.2
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man2/exec.2
and the code is in sys1.c, e.g. E2BIG,
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/ken/sys1.c

> The PWB changes to v6 included a rewrite of exec() to accumulate the argument
> list in swap space, so it could be much longer; the maximum length was a
> parameter, NCARGS, which was set to 5120 (10 blocks) by default.

V7 then also implemented NCARGS (sys/param.h).

I can't read assembler and tried to find the limit in a running V1
http://code.google.com/p/unix-jun72/
with a script which just echoes its arguments, and found
- command line (script or interactive) not longer than 255 characters
- single argument not longer than about 82 characters  (how this might have come off?)
Exceeding this lead to data corruption or kernel crash.

Early exec(2) reads
V1: The arguments are placed as high as possible incore: just below 60000(8).
V3: The arguments are placed as high as possible in core: just below 57000(8).
and I wonder if it's possible to determine limits from this.

Sven

(I was interested in ARG_MAX in general and collected my experiences on
 http://www.in-ulm.de/~mascheck/various/argmax/)

[TUHS] unix v5 limitations

[Noel Chiappa]

    > From: Mark Longridge <cubexyz at gmail.com>

    > The first problem I had was I couldn't just cp over all the
    > /usr/source/s1 files to the new drive because of "Arg list too long"

John Cowan nailed this; as an aside, I don't know about V5, but in vanilla V6
the entire argument list had to fit into one disk buffer (I would assume V5 is
the same).

The PWB changes to v6 included a rewrite of exec() to accumulate the argument
list in swap space, so it could be much longer; the maximum length was a
parameter, NCARGS, which was set to 5120 (10 blocks) by default.

       Noel