[9fans] FS question

[9fans] FS question

[Brantley Coile]

I was just curious to the reasoning behind dropping links.
Did, for example, Ken's FS not do links because Plan 9 had
bind or did Plan 9 use bind because, possibly among other reasons,
FS didn't do any links.  Or was it just an accident of
design, a side affect of putting the file name in the meta data?

Just curious.

 Brantley

Re: [9fans] FS question

[Russ Cox]

> I was just curious to the reasoning behind dropping links.
> Did, for example, Ken's FS not do links because Plan 9 had
> bind or did Plan 9 use bind because, possibly among other reasons,
> FS didn't do any links.  Or was it just an accident of
> design, a side affect of putting the file name in the meta data?

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.

Re: [9fans] FS question

[Rob Pike]

> I was just curious to the reasoning behind dropping links.
> Did, for example, Ken's FS not do links because Plan 9 had
> bind or did Plan 9 use bind because, possibly among other reasons,
> FS didn't do any links.  Or was it just an accident of
> design, a side affect of putting the file name in the meta data?

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

Re: [9fans] FS question

[Brantley Coile]

On Mon, 10 Nov 2003 08:40:11 -0800, Rob Pike <rob@mightycheese.com> wrote:

>> I was just curious to the reasoning behind dropping links.
>> Did, for example, Ken's FS not do links because Plan 9 had
>> bind or did Plan 9 use bind because, possibly among other reasons,
>> FS didn't do any links.  Or was it just an accident of
>> design, a side affect of putting the file name in the meta data?
>
> 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

Re: [9fans] FS question

[Brantley Coile]

On Mon, 10 Nov 2003 10:07:47 -0500, Russ Cox <rsc@swtch.com> wrote:

>> I was just curious to the reasoning behind dropping links.
>> Did, for example, Ken's FS not do links because Plan 9 had
>> bind or did Plan 9 use bind because, possibly among other reasons,
>> FS didn't do any links.  Or was it just an accident of
>> design, a side affect of putting the file name in the meta data?
>
> 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.
>
>


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

Re: [9fans] FS question

[ron minnich]

On Mon, 10 Nov 2003, Brantley Coile wrote:

> 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

Re: [9fans] FS question

[Russ Cox]

> 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?

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

Re: [9fans] FS question

[Sape Mullender]

>> Why was putting the name in the metat good in 1987 but bad
>> in 1969?
>
> I don't think it was bad in 1969.  I think it just didn't
> happen that way.

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.

Re: [9fans] FS question

[Geoff Collyer]

I didn't use the original Unix file system, but the V6-era (ca. 1975)
one was simple yet provided substantial utility.  The main uses of
links that I can recall were locking and renaming.  Linking to an
agreed-upon name was atomic and formed the basis for most locking by
cooperating processes before things like lockf and flock (and
eventually the 'l' bit).

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).

Re: [9fans] FS question

[Dennis Ritchie]

Sape said,

 > 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

Re: [9fans] FS question

[Charles Forsyth]

>>Why was putting the name in the metat good in 1987 but bad
>>in 1969?

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.

[9fans] FS question

[Andrew Simmons]

> You can call me Susan if it makes you happy.

A Boyd named Sue? There could be a song in there somewhere.

Re: [9fans] FS question

[Dan Cross]

"Skip Tavakkolian" <fst@centurytel.net> writes:
> Welcome back Susan.

``Surely you're not serious!''
``I am serious.  And don't call me Shirley.''

	- Dan C.

Re: [9fans] FS question

[Skip Tavakkolian]

> You can call me Susan if it makes you happy.

Welcome back Susan.

Re: [9fans] FS question

[boyd, rounin]

> Boyd,
>
> Is it just me, or have you been gone the same period
> that Rush Limbaugh has been in rehab?

ask rush.  i don't remember a thing.

Re: [9fans] FS question

[boyd, rounin]

> Welcome back. Do you mind if we call you "Bruce" to avoid any confusion?

You can call me Susan if it makes you happy.

    -- Bullet Tooth Tony

Re: [9fans] FS question

[Brantley Coile]

Boyd,

Is it just me, or have you been gone the same period
that Rush Limbaugh has been in rehab?

 Brantley

On Thu, 13 Nov 2003 08:55:43 +1300, Andrew Simmons <andrew.simmons@monitorbm.co.nz> wrote:

>
>>
>> or, boyd
> Welcome back. Do you mind if we call you "Bruce" to avoid any confusion?
>
>

Re: [9fans] FS question

[Andrew Simmons]

>
>or, boyd
Welcome back. Do you mind if we call you "Bruce" to avoid any confusion?

Re: [9fans] FS question

[Boyd Roberts]

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

"Lucio De Re" <lucio@proxima.alt.za> a �crit dans le message de
news:20031111142831.C6815@cackle.proxima.alt.za...
> On Tue, Nov 11, 2003 at 09:26:24PM +1100, Bruce Ellis wrote:
> >
> > that's not me.  just in case you guys thought i'd gone into IT.
> >
> > brucee
>
> No, we know you Australians are all named either Bruce or Sheila ;-)
>
> ++L

or, boyd

Re: [9fans] FS question

[Lucio De Re]

On Tue, Nov 11, 2003 at 09:26:24PM +1100, Bruce Ellis wrote:
>
> that's not me.  just in case you guys thought i'd gone into IT.
>
> brucee

No, we know you Australians are all named either Bruce or Sheila ;-)

++L

Re: [9fans] FS question

[Bruce Ellis]

that's not me.  just in case you guys thought i'd gone into IT.

brucee
----- Original Message -----
From: <bruce@it.usyd.edu.au>
To: <9fans@cse.psu.edu>
Sent: Tuesday, November 11, 2003 1:30 PM
Subject: Re: [9fans] FS question


> If a file could be removed but still remain accessible
> (via an open file descriptor) then that might suggest an implementation
> where the file was distinct from its name.  Once that separation
> existed then it might have been thought interesting to allow
> multiple names for the same file.
>
> What did Multics do?
> ken?

Re: [9fans] FS question

[bruce]

If a file could be removed but still remain accessible
(via an open file descriptor) then that might suggest an implementation
where the file was distinct from its name.  Once that separation
existed then it might have been thought interesting to allow
multiple names for the same file.

What did Multics do?
ken?