[TUHS] Unix v6 problem with /tmp

[TUHS] Unix v6 problem with /tmp

[Norman Wilson]

William Pechter:

  Only thing I can think of is add another drive or partition and mount it
  as /tmp.

=====

You say that as if it's a bad thing.

Norman Wilson
Toronto ON
mount >> ln -s

[TUHS] Unix v6 problem with /tmp

[William Pechter]

Clem cole wrote:
> Yep.  We used it for both but discovered it tended to be better for our system as a /tmp because we tried really hard to keep the 11/70 from swapping in those days. 
>
> Clem
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

That gave the AT&T folks (and Regional Bells) a major improvement over
the RS04 (and less of a maintenance problem) and the Computer Special
Systems folks at DEC had a way to use less than perfect MK11 memory
since the embedded internal ML11 disk controller mapped out bad blocks
in NVRAM  so it looked like a clean disk. I remember stories about a 3x
improvement in some of the 11/70's jobs,

I don't know what apps were on the box.  Might have been COSMOS or
something else.

When I saw the Windows Ready Boost and Intel Turbo memory I really
flashed (ugh pun not intended) to the day I installed the early
ML11... Nothing new in the OS business that wasn't done in the old
days.  Unfortunately, there's very little love for history in the industry.
My college major was history... so I love the connected nature of the
designs.  It's all an evolution.


Bill
>> On Jul 27, 2016, at 5:10 PM, William Pechter <pechter at gmail.com> wrote:
>>
>> Clem Cole wrote:
>>> That is exactly how its was done.   In fact, DEC made a Solid State Disk (out of RAM) just for UNIX that people used to use for /tmp.
>> Are you referring to the slick little ML11-A  (I think it was an -A when I installed it at NY Telephone on
>> West Street, next to the World Trade Center...
>>
>> I seem to remember it being used as an RS04 (or similar) fixed head disk replacement for swap -- but
>> it could've been used for temp.
>>
>> Funny seeing a fault light on a Massbus controller'd box of mostly MK11 memory.
>> IIRC it had write-lock as well.
>>
>> Neat idea and I wish someone would come up with a really large SSD with a writelock for archival storage
>> of my stuff.  No head crashes and if I could disable the possibility of accidental writing...
>>
>> Bill
>>
>> -- 
>> Digital had it then.  Don't you wish you could buy it now!
>> pechter-at-gmail.com  http://xkcd.com/705/
>>

[TUHS] Unix v6 problem with /tmp

[Clem cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

Bill - below

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Jul 27, 2016, at 5:10 PM, William Pechter <pechter at gmail.com> wrote:
> 
> Neat idea and I wish someone would come up with a really large SSD with a writelock for archival storage
> of my stuff.  No head crashes and if I could disable the possibility of accidental writing...

I had to laugh.   A few months back I was working with a very bright 20 something engineers (from one of my alma mater's ) who is working on our new Xpoint memory technology.   I had to explain to him some of these new behaviors / inventions were how things like core memory worked as well as showing him some info on the ML11 with exactly these type of features.   He had no idea.  

While I'm not part of the the Xpoint team I have no idea what will end up as exposed features in final product  or how people configure them but it's interesting to watch some ideas that stopping being fashionable or maybe economical be (re)discovered. 

What is new is old and old is now new😎

Clem

[TUHS] Unix v6 problem with /tmp

[Clem cole]

Yep.  We used it for both but discovered it tended to be better for our system as a /tmp because we tried really hard to keep the 11/70 from swapping in those days. 

Clem

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Jul 27, 2016, at 5:10 PM, William Pechter <pechter at gmail.com> wrote:
> 
> Clem Cole wrote:
>> That is exactly how its was done.   In fact, DEC made a Solid State Disk (out of RAM) just for UNIX that people used to use for /tmp.
> Are you referring to the slick little ML11-A  (I think it was an -A when I installed it at NY Telephone on
> West Street, next to the World Trade Center...
> 
> I seem to remember it being used as an RS04 (or similar) fixed head disk replacement for swap -- but
> it could've been used for temp.
> 
> Funny seeing a fault light on a Massbus controller'd box of mostly MK11 memory.
> IIRC it had write-lock as well.
> 
> Neat idea and I wish someone would come up with a really large SSD with a writelock for archival storage
> of my stuff.  No head crashes and if I could disable the possibility of accidental writing...
> 
> Bill
> 
> -- 
> Digital had it then.  Don't you wish you could buy it now!
> pechter-at-gmail.com  http://xkcd.com/705/
> 

[TUHS] Unix v6 problem with /tmp

[Clem cole]

Certainly 4.2 was were most people found them and the UNIX community at large saw them and I do not wAnt to disparage my siblings at Berkeley for the fine work done there. 


 But particularly since Dennis has passed I hate seeing history get forgotten/rewritten.  I can tell you I personally I remember talking to Dennis and Steve Bourne about the idea of late binding for nami pre-BSD 3x UNIX days  - late 1979 is my guess might have been a little later.  Dennis would have been messing with them in a post V7 systems.  I would have been at Tek @ the time.  Joy probable would have seen them as a summer intern at the labs and talked to him about it then.  

You are right the BSD 4.2 made the world know about them but like a number of things in BSD (such as networking) it was in some cases a (better) integration of ideas others had played with before. 




Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Jul 27, 2016, at 5:18 PM, Norman Wilson <norman at oclsc.org> wrote:
> 
> I'm pretty sure they came from Berkeley nevertheless

[TUHS] Unix v6 problem with /tmp

[Norman Wilson]

Clem Cole:

  Also to be fair, Dennis did symlinks before 4.2.   They were part of the V8
  I believe.

=======

I'm pretty sure they came from Berkeley nevertheless.  I don't know
the exact order of events, but the 8th Edition kernel was essentially
that from one of the later 4.1x BSDs, hacked in 1127 to remove sockets
and FFS (were they even there yet), then to add Dennis's stream I/O
system, Tom Killian's original /proc, and Peter Weinberger's neta
network-file-system client.  Perhaps a few other hooks as well.
Symlinks were already there, and although we made some limited careful
use of them, made nobody very happy because they made such a big
irregular lump in so many things: file system no longer a tree,
difference between stat and lstat, and so on.

One thing 8/e did differently from Berkeley was that ls by default
hid symlinks rather than trotting them out proudly.  If f was a
symlink, ls -l f showed the state of the target file, not that of
the link; one had to do ls -lL f to see the symlink itself.
That reflected a general feeling that symlinks should be neither
seen nor heard unless necessary.

Norman Wilson
Toronto ON

[TUHS] Unix v6 problem with /tmp

[William Pechter]

Clem Cole wrote:
> That is exactly how its was done.   In fact, DEC made a Solid State 
> Disk (out of RAM) just for UNIX that people used to use for /tmp.
>
Are you referring to the slick little ML11-A  (I think it was an -A when 
I installed it at NY Telephone on
West Street, next to the World Trade Center...

I seem to remember it being used as an RS04 (or similar) fixed head disk 
replacement for swap -- but
it could've been used for temp.

Funny seeing a fault light on a Massbus controller'd box of mostly MK11 
memory.
IIRC it had write-lock as well.

Neat idea and I wish someone would come up with a really large SSD with 
a writelock for archival storage
of my stuff.  No head crashes and if I could disable the possibility of 
accidental writing...

Bill

-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-gmail.com  http://xkcd.com/705/

[TUHS] Unix v6 problem with /tmp

[Clem Cole]

BTW: Mark if you are running on a simulator, just create an extra drive in
the RK05 driver, put 4280 blocks on it and mount it on /tmp in /etc/rc when
you go multi-user.     You should be all set, and you will be running like
many/most V6 and V7 systems in years gone by.

On Wed, Jul 27, 2016 at 4:57 PM, Clem Cole <clemc at ccc.com> wrote:

> That is exactly how its was done.   In fact, DEC made a Solid State Disk
> (out of RAM) just for UNIX that people used to use for /tmp.
>
>
> Also to be fair, Dennis did symlinks before 4.2.   They were part of the
> V8 I believe.  I remember talking to him and Steve Bourne about them and
> ideas in the FS.  Dennis's basic thesis was that while UNIX had a typed
> file system, he & Ken intentionally kept the number of types very very
> small.    The problem he was afraid of what that too many systems had ended
> up so many different ways to handle things.    Just keep everything as a
> ASCII text file and let the user space deal with it.   Symlinks, or "late
> name binding" for the FS was a mixed bag.    Just as Dennis predicted,
> Solaris was an example of an implementation that went symlink happy.
>
> I created Conditionally Dependant Symlinks (CDSL) which I think only
> showed up in Masscomp's RTU, Stellix and Tru64.   The were not only late
> binding, but added the concept of a user settable context.   Very handy
> when trying to create a "single system image" from multiple system.   I
> miss them today from Linux clusters and even put them back into one of my
> systems.   B
>
>
> Also, around the same time that Dennis added symlinks, Apollo's Aegis (aka
> Domain) guys came up with a cool idea where you can run application code
> from a link - extensible types.    I remember talking to Dennis and Ken
> about them at a SOSP IIRC, and toyed with putting them into one of the
> Locus UNIX Kernels.   We proposed it for HP-UX and Tru64, but never got
> funded to try it, although I think / believe others did some where else.
>
>
>
> On Wed, Jul 27, 2016 at 4:31 PM, William Pechter <pechter at gmail.com>
> wrote:
>
>> Mark Longridge wrote:
>> > Hi folks,
>> >
>> > My root partition for Unix v6 is almost full and /dev/rk0 only has 83
>> blocks.
>> >
>> > The trouble is I wanted to compile bc.y and I think it needs around
>> > 300 blocks of temporary space. I was wondering if there was a way to
>> > set up Unix v6 so that it could use one of the other drives for tmp
>> > space. I tried to set up a link using ln but it seems I can't link
>> > across filesystems.
>> >
>> > The exact error is "26: Intermediate file error".
>> >
>> > I managed to rearrange things so that /dev/rk0 had over 300 blocks of
>> > free space and it fixed the problem, but I'm curious if there was
>> > another solution.
>> >
>> > Mark
>> Ah the good old days before BSD's symlinks.
>> Only thing I can think of is add another drive or partition and mount it
>> as /tmp.
>>
>>
>> Bill
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160727/7acc6cf3/attachment-0001.html>

[TUHS] Unix v6 problem with /tmp

[Clem Cole]

That is exactly how its was done.   In fact, DEC made a Solid State Disk
(out of RAM) just for UNIX that people used to use for /tmp.


Also to be fair, Dennis did symlinks before 4.2.   They were part of the V8
I believe.  I remember talking to him and Steve Bourne about them and ideas
in the FS.  Dennis's basic thesis was that while UNIX had a typed file
system, he & Ken intentionally kept the number of types very very small.
 The problem he was afraid of what that too many systems had ended up so
many different ways to handle things.    Just keep everything as a ASCII
text file and let the user space deal with it.   Symlinks, or "late name
binding" for the FS was a mixed bag.    Just as Dennis predicted, Solaris
was an example of an implementation that went symlink happy.

I created Conditionally Dependant Symlinks (CDSL) which I think only showed
up in Masscomp's RTU, Stellix and Tru64.   The were not only late binding,
but added the concept of a user settable context.   Very handy when trying
to create a "single system image" from multiple system.   I miss them today
from Linux clusters and even put them back into one of my systems.   B


Also, around the same time that Dennis added symlinks, Apollo's Aegis (aka
Domain) guys came up with a cool idea where you can run application code
from a link - extensible types.    I remember talking to Dennis and Ken
about them at a SOSP IIRC, and toyed with putting them into one of the
Locus UNIX Kernels.   We proposed it for HP-UX and Tru64, but never got
funded to try it, although I think / believe others did some where else.



On Wed, Jul 27, 2016 at 4:31 PM, William Pechter <pechter at gmail.com> wrote:

> Mark Longridge wrote:
> > Hi folks,
> >
> > My root partition for Unix v6 is almost full and /dev/rk0 only has 83
> blocks.
> >
> > The trouble is I wanted to compile bc.y and I think it needs around
> > 300 blocks of temporary space. I was wondering if there was a way to
> > set up Unix v6 so that it could use one of the other drives for tmp
> > space. I tried to set up a link using ln but it seems I can't link
> > across filesystems.
> >
> > The exact error is "26: Intermediate file error".
> >
> > I managed to rearrange things so that /dev/rk0 had over 300 blocks of
> > free space and it fixed the problem, but I'm curious if there was
> > another solution.
> >
> > Mark
> Ah the good old days before BSD's symlinks.
> Only thing I can think of is add another drive or partition and mount it
> as /tmp.
>
>
> Bill
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160727/cc4540f6/attachment.html>

[TUHS] Unix v6 problem with /tmp

[William Pechter]

Mark Longridge wrote:
> Hi folks,
>
> My root partition for Unix v6 is almost full and /dev/rk0 only has 83 blocks.
>
> The trouble is I wanted to compile bc.y and I think it needs around
> 300 blocks of temporary space. I was wondering if there was a way to
> set up Unix v6 so that it could use one of the other drives for tmp
> space. I tried to set up a link using ln but it seems I can't link
> across filesystems.
>
> The exact error is "26: Intermediate file error".
>
> I managed to rearrange things so that /dev/rk0 had over 300 blocks of
> free space and it fixed the problem, but I'm curious if there was
> another solution.
>
> Mark
Ah the good old days before BSD's symlinks.
Only thing I can think of is add another drive or partition and mount it
as /tmp.


Bill

[TUHS] Unix v6 problem with /tmp

[Mark Longridge]

Hi folks,

My root partition for Unix v6 is almost full and /dev/rk0 only has 83 blocks.

The trouble is I wanted to compile bc.y and I think it needs around
300 blocks of temporary space. I was wondering if there was a way to
set up Unix v6 so that it could use one of the other drives for tmp
space. I tried to set up a link using ln but it seems I can't link
across filesystems.

The exact error is "26: Intermediate file error".

I managed to rearrange things so that /dev/rk0 had over 300 blocks of
free space and it fixed the problem, but I'm curious if there was
another solution.

Mark