6 Nov
2018
6 Nov
'18
6:09 p.m.
I was wondering, what was the /crp mount point in early UNIX used for?
And what does "crp" mean? Does it mean what I think it does?
It is only mentioned in V3 it seems:
./v4man/manx/unspk.8:unspk lives in /crp/vs (v4/manx means pre-v4)
./v3man/man6/yacc.6:SYNOPSIS /crp/scj/yacc [ <grammar ]
./v3man/man4/rk.4:/dev/rk3 /crp file system
I suppose scj, doug or ken can help out.
aap
6 Nov
6 Nov
8:22 p.m.
The "crp" user name was Chuck Privitera. Don't know if it was him or
they
just had a disk they dumped cr..p on ...
-----Original Message-----
From: TUHS <tuhs-bounces(a)minnie.tuhs.org> On Behalf Of Angelo
Papenhoff
Sent: Tuesday, November 6, 2018 12:10 PM
To: tuhs(a)minnie.tuhs.org
Subject: [TUHS] /crp
I was wondering, what was the /crp mount point in early UNIX used for?
And what does "crp" mean? Does it mean what I think it does?
It is only mentioned in V3 it seems:
./v4man/manx/unspk.8:unspk lives in /crp/vs (v4/manx means pre-v4)
./v3man/man6/yacc.6:SYNOPSIS /crp/scj/yacc [ <grammar ]
./v3man/man4/rk.4:/dev/rk3 /crp file system
I suppose scj, doug or ken can help out.
aap
8:25 p.m.
An early UNIX paper shows the system had four RK05's (4872 512-byte blocks
on UNIX, for some reason only 4800 used on the DEC OSs ... remember we had
to poke ROLLIN to copy the full UNIX partition standalone).
/dev/rk0 - available for user packs.
/dev/rk1 - root
/dev/rk2 - /usr
/dev/rk3 - /crp
I think it was just additional storage of "crap".
-----Original Message-----
From: TUHS <tuhs-bounces(a)minnie.tuhs.org> On Behalf Of Angelo
Papenhoff
Sent: Tuesday, November 6, 2018 12:10 PM
To: tuhs(a)minnie.tuhs.org
Subject: [TUHS] /crp
I was wondering, what was the /crp mount point in early UNIX used for?
And what does "crp" mean? Does it mean what I think it does?
It is only mentioned in V3 it seems:
./v4man/manx/unspk.8:unspk lives in /crp/vs (v4/manx means pre-v4)
./v3man/man6/yacc.6:SYNOPSIS /crp/scj/yacc [ <grammar ]
./v3man/man4/rk.4:/dev/rk3 /crp file system
I suppose scj, doug or ken can help out.
aap
10:51 p.m.
On Tue, 6 Nov 2018, ron(a)ronnatalie.com wrote:
An early UNIX paper shows the system had four
RK05's (4872 512-byte
blocks on UNIX, for some reason only 4800 used on the DEC OSs ...
remember we had to poke ROLLIN to copy the full UNIX partition
standalone).
Bad blocks? I think I have an article in AUUGN where I proposed that bad
blocks be assigned (somehow) to a pseudo-file as inode #0 (or -1?); that
way, the "dump" utility would not see it, and neither would the FS tools
(but a disk image would, of course).
/dev/rk0 - available for user packs.
/dev/rk1 - root
Odd layout... I normally saw them the other way around.
-- Dave
7 Nov
7 Nov
1:18 p.m.
:
way,
An early UNIX paper shows the system had four
RK05's (4872 512-byte
blocks on UNIX, for some reason only 4800 used on the DEC OSs ...
remember we had to poke ROLLIN to copy the full UNIX partition
standalone).
Bad blocks? I think I have an article in AUUGN where I proposed that bad
blocks be assigned (somehow) to a pseudo-file as inode #0 (or -1?); that the "dump" utility would not see it, and
neither would the FS tools (but a
disk
image would, of course).
No, not to my knowledge. The DEC drivers just left off the last 72
sectors. There was no provision using them for block replacement.
The utilities just stopped at 4800.
4:14 p.m.
On Wed, Nov 7, 2018 at 9:09 AM <ron(a)ronnatalie.com> wrote:
The DEC drivers just left off the last 72 sectors.
There was no
provision using them for block replacement.
Minor update -- *no dynamic replacement provision*. There was a standard
alone utility called BAD144 that implemented DEC Standard 144 (Bad
Blocks). What would happen is that the format was messed with the point a
bad block at on the reserved sectors.
This scheme caused nasty performance issues because seek schedualing was
defeated; and since UNIX did not originally obey DEC STD144, the standard
UNIX scheme in those days was buy 'perfect' media. BTW: the Ultrix team -
Fred Canter IIRC -- added support for BAD144, and I think DEC gave that
code to BSD evetually.
Clem
ᐧ
8 Nov
8 Nov
12:40 a.m.
On Wednesday, 7 November 2018 at 10:14:20 -0500, Clem Cole wrote:
On Wed, Nov 7, 2018 at 9:09 AM
<ron(a)ronnatalie.com> wrote:
Yes, this was also present in early FreeBSD distributions. I have a
vague recollection that people warned against using it.
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
The DEC drivers just left off the last 72
sectors. There was no
provision using them for block replacement.
Minor update -- *no dynamic replacement provision*. There was a
standard alone utility called BAD144 that implemented DEC Standard
144 (Bad Blocks). 
4:04 a.m.
On Wed, Nov 7, 2018 at 7:26 PM Greg 'groggy' Lehey <grog(a)lemis.com>
wrote:
On Wednesday, 7 November 2018 at 10:14:20 -0500, Clem
Cole wrote:
It was OK for the super-duper old IDE drives from the IBM/AT and 80386 era.
It was better for the ESDI drives because those tended to ship with a list
of bad blocks printed on the label (which was itself a carry over from the
MFM days). The MFM drives *did* have a DEC standard to list bad blocks and
reserve spare cylinders which was derived from the earlier rkXX drives.
bad144 was for the rkXX drives and then adopted, badly, for the newer
drives types and wasn't super-great by the time FreeBSD came along...
Warner
On Wed, Nov 7, 2018 at 9:09 AM
<ron(a)ronnatalie.com> wrote:
Yes, this was also present in early FreeBSD distributions. I have a
vague recollection that people warned against using it.
The DEC drivers just left off the last 72
sectors. There was no
provision using them for block replacement.
Minor update -- *no dynamic replacement provision*. There was a
standard alone utility called BAD144 that implemented DEC Standard
144 (Bad Blocks). 
7 Nov
7 Nov
5:43 p.m.
On 11/6/18, Dave Horsfall <dave(a)horsfall.org> wrote:
Bad blocks? I think I have an article in AUUGN where I proposed that bad
blocks be assigned (somehow) to a pseudo-file as inode #0 (or -1?); that
way, the "dump" utility would not see it, and neither would the FS tools
(but a disk image would, of course).
That is how VMS handles bad blocks. When the system detects them,
they are allocated to file BADBLK.SYS;1 in the volume's root
directory. Of course, these days the disk hardware controller handles
bad blocks. The VMS engineering group once got a bug report
complaining that when a privileged user issued the command "type
dba0:[000000]badblk.sys" there were scads and scads of bad block error
messages.
"Doctor, it hurts when I do this...."
-Paul W.
8 Nov
8 Nov
5:55 p.m.
I recall at Berkeley on the VAX we had a /crp filesystem, and it was for
"crap" we didn't want to delete but wasn't very important. I
didn't
realize it was inspired by Research.
At some point someone decided it would be nicer to rename it /arch as an
"archive".
I still have a /arch on my personal machine, for stuff that's large and
(almost) never changes, so it doesn't need to be backed up daily. It
lives on one of those external backup hard disks, and there are two of
them, so one can be stored offsite.
Mary Ann
On 11/6/18 11:25 AM, ron(a)ronnatalie.com wrote:
An early UNIX paper shows the system had four
RK05's (4872 512-byte blocks
on UNIX, for some reason only 4800 used on the DEC OSs ... remember we had
to poke ROLLIN to copy the full UNIX partition standalone).
/dev/rk0 - available for user packs.
/dev/rk1 - root
/dev/rk2 - /usr
/dev/rk3 - /crp
I think it was just additional storage of "crap".
> -----Original Message-----
> From: TUHS <tuhs-bounces(a)minnie.tuhs.org> On Behalf Of Angelo
> Papenhoff
> Sent: Tuesday, November 6, 2018 12:10 PM
> To: tuhs(a)minnie.tuhs.org
> Subject: [TUHS] /crp
>
> I was wondering, what was the /crp mount point in early UNIX used for?
> And what does "crp" mean? Does it mean what I think it does?
> It is only mentioned in V3 it seems:
> ./v4man/manx/unspk.8:unspk lives in /crp/vs (v4/manx means pre-v4)
> ./v3man/man6/yacc.6:SYNOPSIS /crp/scj/yacc [ <grammar ]
> ./v3man/man4/rk.4:/dev/rk3 /crp file system
>
> I suppose scj, doug or ken can help out.
>
> aap
2201
days inactive
2204
days old
10 comments
9 participants
participants (9)
-
Angelo Papenhoff -
Clem Cole -
Dave Horsfall -
Greg 'groggy' Lehey -
Lars Brinkhoff -
Mary Ann Horton -
Paul Winalski -
ron＠ronnatalie.com -
Warner Losh