It's a bit off-topic, but what were non-Unix filesystems like around 1969-1970?
The PDP-7 filesystem has i-nodes (file metadata) and filenames separate
from the i-nodes. This allows hard links and thus a non-tree structured
filesystem.
This has always struck me to be one of the most important features of
the Unix filesystem: names separated from the rest of the file metadata,
and arbitrary hard links so that there is no preferred filename.
Were these features in other contemporaneous filesystems?
As a side note, the PDP-7 kernel knows about the top-level directory ("dd")
but it is agnostic to the concept of "." and "..". What that means is
that you can build a filesystem with "." and ".." links and the kernel
will deal with them as per all other links. But you can also build a
filesystem without "." or ".." and the kernel doesn't care.
There's not enough evidence (source code, papers, anecdotes) to confirm
or deny the presence of "." in the PDP-7 code that Norman scanned for us.
".." does seem to exist as it is mentioned in one source file, ds.s.
It's an intruiging mystery.
Cheers, Warren
This came up today at work; what's the origin of the open file table? The
suggestion was made that, instead, a ref-counted data structure could be
allocated at open() time to serve the same purpose, and that a table of
open files was superfluous. My guess was that this made it (relatively)
easy to look up what files referred to a particular device?
> Those file structures are collected into a single, global table. The
> question is why this latter table? One could rather imagine an
> implementation where open() allocates (e.g., via malloc())
Depending on how malloc() is implemented, fragmentation can be
serious in a program that runs forever with as many frees as
allocs. Separate allocations for each item can also be costly in time.
One malloc() strategy is to divide the arena into regions,
each of which caters for blocks of a single size, so
fragmentation doesn't occur. In essence that's how the
system tables work, except that these tables have
hard limits. Now, if the tables could be reallocated
as needed ...
Another problem with per-item allocations is performance
monitoring and debugging. It's hard to see what's
going on in a well mixed dynamic storage heap.
Doug
https://newsroom.intel.com/news-releases/andrew-s-grove-1936-2016/
I know some of the processor people at intel and I was looking around,
found this, interesting read if you are into the history:
http://people.cs.clemson.edu/~mark/330/chronques.html
For those that don't know, Colwell did the P6 pipeline, I think under
Groove or right after Groove got cancer. There was P5, then P6, then
they did a different pipeline that they called Pentium 4 (made no sense
to me but their names never do). The Pentium 4 was the one where
they speculated on what the answer would be for some instructions.
As in you could do a load and they'd guess that it was zero or not.
They were going for great clock rate, and they got it, but they also
got instructions that would take 2000 cycles to get through.
That pipeline got booted and so far as I know, the Colwell P6 pipeline
lives on in every Intel processor after the Pentium 4.
Getting back to Andy, I loved his time as CEO, I think he did a lot of
good for that company. Here's to him!
Sorry to continue the detour from disk file systems to card trays, but this
> Walking down the corridors of Comp Sci, a student in front of me
> dropped his entire deck of approx 2000 cards, all over the floor...
> I have no idea whether he got them sorted, but I sure as hell used
> rubber bands after that!
reminded me that Vic Vyssotsky liked to say of his BLODI (block diagram)
language for simulating sample-data systems that it was the only card-safe
language. You could toss a program deck down the stairs, pick it up at the
bottom, submit it to the compiler, and it would work. That was 10 years
before the filing of the famous "natural order" patent on spreadsheets,
which ordered execution the same way.
Doug
On 2016-03-18 03:00, Warren Toomey <wkt(a)tuhs.org> wrote:
> It's a bit off-topic, but what were non-Unix filesystems like around 1969-1970?
> The PDP-7 filesystem has i-nodes (file metadata) and filenames separate
> from the i-nodes. This allows hard links and thus a non-tree structured
> filesystem.
>
> This has always struck me to be one of the most important features of
> the Unix filesystem: names separated from the rest of the file metadata,
> and arbitrary hard links so that there is no preferred filename.
>
> Were these features in other contemporaneous filesystems?
I don't know exactly how contemporary ODS-1 is. It's the file system
used on RSX-11, and I think it should atleast trace back to around 1972,
but I can't say more for sure.
Anyway, ODS-1, just like the Unix file system, have the directory hold
just the filename and a file identifier (pretty much the same as inode
number). There are of course some differences in details, but I would
say it is very similar to how Unix works. ODS-1 do not have reference
counting, but instead allows dangling directory entries that do not
point to valid files. Instead ODS-1 have a generation counter for each
file identifier, so that when it is reused, links to the old file will
not accidentally refer to the new file.
I would think that something like Multics had something similar, but I
have no idea about that one...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
> Were these features [arbitrary hard links] in other contemporaneous filesystems?
Multics had arbitary "links", which were distinguished from "branches"--the
actual file. Links and branches coexisted in directories. Unix was consciously
derived from this model, but simplified so that only links have names
and branches live elsewhere (the inode list). The architecture is
described in http://www.multicians.org/fjcc4.html. This paper is
dates from 1964 or 1965; it was certainly authoritative in 1969.
I don't know whether it evolved further.
Christopher Strachey and Joe Stoy independently conceived a model
isomorphic to Unix for OS 6 at Oxford. The two systems were
essentially contemporaneous.
I am not aware of other systems that allowed multiple names for
one file, though clearly the scent was in the air at the time.
doug
> From: Johnny Billquist
> I would think that something like Multics had something similar
No, as far as I know, Multics was always 'old-style' - the directory contained
not just the name of the file, but also all the file's meta-data. Multics had
only symbolic links, I'm pretty sure.
To answer the original question, I can't think offhand of another system that
separated naming and file meta-data before Unix did it. I've always assumed
that that was one of Unix' novel ideas.
Noel
$ pdp7 unixv0.simh # Run the PDP-7 Unix kernel on SimH
PDP-7 simulator V4.0-0 Beta
sim> c # Start execution
login: ken
password: ken
@ date
Thu Jan 01 1970 00:00:05
@ ls -l
00004 drw-- 01 777 00050 dd
00035 drwr- 01 012 00060 .
00003 drw-- 01 777 00270 system
00036 lrwr- 01 777 00305 date
00037 lrwr- 01 777 00441 ls
@
inum perms lnks uid size file
Root was user-id -1, but the octal print routine sees as an unsigned
int and prints it truncated to three octal digits, 777.
So, the kernel boots and runs.
Cheers, Warren
