Just curious.
Brantley
I have no idea (I wasn't there), but I have a question for you.
If you were designing a file system today, from scratch,
and you weren't worried about backwards compatibility,
would you actually structure it the same way as the UNIX
file system, with inodes and links? What a mess.
links are bizarre, as rsc said.
i don't really know the answer to your question; i think rsc may
have actually done so. when redesigning, you tend to throw
away the stuff you don't want.
also, think how links would work in plan 9. it's bad enough on
unix, where you can't link from one file system to another, even
on the same disk. with plan 9's malleable name spaces and files
appearing from all over, links would work even more unpredictably.
-rob
Just to be on record, I wasn't even remotely suggesting
we put links into Plan 9. I like the way Plan 9 FS does it.
I was just trying to gain insight into how the FS got
to where it is.
Brantley
Since I learned from UNIX, there is a very real chance that
I would structure it that way. It's what I grew up with.
Why was putting the name in the metat good in 1987 but bad
in 1969?
Brantley
> I was just trying to gain insight into how the FS got
> to where it is.
If you think about a PDP-11 or earlier machine, 64 KB address space, and
you look at the file system that ran at that time, the whole i-number and
links thing was a pretty reasonable and efficient way to go. It's really
remarkable that it all worked out so well.
Funny note: At the time lots of people were arguing that a hierarchical
file system was impossibly inefficient, believe it or not. For example, HP
at the time offered a file system with two (2, yes 2) levels of directory;
that's all you got. (this is in the 70s)
It just doesn't make sense nowadays.
ron
I don't think it was bad in 1969. I think it just didn't
happen that way. Look at the way that links were
used before there were hierarchical path names
(see http://plan9.bell-labs.com/~dmr/hist.html, search for "ln dd").
Once you have hierarchical path names so it's easy to name
files that are more than two hops from the current directory,
I think the need for links goes away. They're a holdover from
an earlier time.
In short, modern file names make links unnecessary.
Entirely speculation.
Russ
Indeed. In 1969, directory entries consisted of a (14 character) name and a
(16 bit) inode number. Multiple directory entries could refer to the same
inode: links. Inodes had a reference-count that kept track of the number of
directories pointing to an inode. (the command ncheck would check/fix these
counts).
Symbolic links came much later (in BSD if I remember correctly) and, in early
symbolic links, a single data block would be sacrificed for storing the name linked
to. The name was still not in the inode metadata.
Renaming was done by linking from the old name to the new, then
removing the old name (if the link succeeded). This even worked for
directories (adding some fiddling with .. entries) and let one move
files and directories anywhere within a given file system's directory
tree. The modern (Berkeley) rename() primitive is by contrast very
difficult to get right, taking into account races and potential errors
of various sorts. The one thing that links permitted and that I miss
in Plan 9 is being able to efficiently move directories arbitrarily
within a file system, though it's less of an issue than on Unix, where
shuffling directory hierarchies was the vendors' and standards bodies'
equivalent of corporate reorganisation (i.e., we'll rename everything
and hope that nobody notices that we haven't done much else).
> Symbolic links came much later (in BSD if I remember correctly) and, in early
> symbolic links, a single data block would be sacrificed for storing the name linked
> to. The name was still not in the inode metadata.
Yes. Actually I was the first to implement symbolic links,
in a post-V7 system, but it was after CSRG (and their ARPA
oversight committee, of which I was a member) decided to
implement them. I sent the code to CSRG.
I argued at the time that two kinds of links was
one too many, and it would be good to get rid of
the hard links. Neither they nor we did this
in stock Unix, of course.
Dennis
What did Multics do?
ken?
brucee
No, we know you Australians are all named either Bruce or Sheila ;-)
++L
or, boyd
Is it just me, or have you been gone the same period
that Rush Limbaugh has been in rehab?
Brantley
You can call me Susan if it makes you happy.
-- Bullet Tooth Tony
ask rush. i don't remember a thing.
actually the other way round (name and metadata in directory representation)
was more the norm in 1969 and later. the unix approach was unusual.
other systems had the equivalent of links only when something went
terribly wrong and aliased file or directory storage references. the unix structure was
quite cute really for minimalism, but it began to stumble over the boundaries
between file systems. to be fair, there were approximations to striping/mirroring drivers
not all that much later that eliminated the need to stumble so soon, but they weren't widely used.
That would be me, Michael Baldwin, even though I'm not from Pommyland.
Welcome back Susan.
this is gonna be fun. :-)
``Surely you're not serious!''
``I am serious. And don't call me Shirley.''
- Dan C.
brucee
----- Original Message -----
A Boyd named Sue? There could be a song in there somewhere.