From: Rob Pike <robpike@gmail.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: TUHS main list <tuhs@minnie.tuhs.org>,
Noel Chiappa <jnc@mercury.lcs.mit.edu>
Subject: Re: [TUHS] moving directories in svr2
Date: Fri, 31 Dec 2021 14:23:15 +1100 [thread overview]
Message-ID: <CAKzdPgzOBKEaMdCGxKirP4cxSDeBZrU6VO78JFpxf05vi-5_AQ@mail.gmail.com> (raw)
In-Reply-To: <Yc50LSUs7B790YFG@mit.edu>
[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]
In broad strokes, that's exactly what we did in Plan 9, with great results,
as was said here a while back. The paper ended with a plea to do the same
to Unix, which I think is quite doable.
https://9p.io/sys/doc/lexnames.html
-rob
On Fri, Dec 31, 2021 at 2:09 PM Theodore Ts'o <tytso@mit.edu> wrote:
> On Thu, Dec 30, 2021 at 05:31:09PM -0500, Dan Cross wrote:
> > On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o <tytso@mit.edu> wrote:
> > > On Wed, Dec 29, 2021 at 10:45:12PM -0500, Noel Chiappa wrote:
> > > > > From: Bakul Shah
> > > >
> > > > > My guess is *not* storing a path instead of a ptr to the inode
> was done
> > > > > to save on memory.
> > > >
> > > > More probably speed; those old disks were not fast, and on a PDP-11,
> disk
> > > > caches were so small that converting the path to the current
> directory to its
> > > > in memory inode could take a bunch of disk reads.
> > >
> > > The other problem with storing the path as a string is that if
> > > higher-level directories get renamed, the path would become
> > > invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone
> > > renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string would
> > > become invalidated.
> >
> > Why? Presumably as you traversed the filesystem, you'd cache, (path
> > component, inode) pairs and keep a ref on the inode. For any given
> > file, including $CWD, you'd know it's pathname from the root as you
> > accessed it, but if it got renamed, it wouldn't matter because you'd
> > have cached a reference to the inode.
>
> I was responding to Bakul's suggestion that the original Unix
> could/should have stored the cwd as a string, instead of a pointer to
> a directory inode. If you stored the cwd as a string, then you could
> interpret .. by chopping off the last file name component of the
> string, and so now you could have hard links to directories and the
> file system tree could then be a file system DAG.
>
> I don't think Bakul's proposal would have worked --- although I
> suppose if you disallowed directory renames, I guess it could. Noel's
> objection above was a performance one, in that if you had to parse the
> path every single time, you'd be much more dependent on the namei
> cache --- and that PDP-11 didn't have the memory to support a
> sufficiently large cache.
>
> - Ted
>
>
[-- Attachment #2: Type: text/html, Size: 3238 bytes --]
next prev parent reply other threads:[~2021-12-31 3:23 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-30 3:45 Noel Chiappa
2021-12-30 4:02 ` Bakul Shah
2021-12-30 16:40 ` Theodore Ts'o
2021-12-30 22:31 ` Dan Cross
2021-12-31 0:43 ` Bakul Shah
2021-12-31 1:00 ` Rob Pike
2021-12-31 1:45 ` Bakul Shah
2021-12-31 2:23 ` Adam Thornton
2021-12-31 18:56 ` Chet Ramey
2021-12-31 3:08 ` Theodore Ts'o
2021-12-31 3:23 ` Rob Pike [this message]
2021-12-31 5:16 ` Theodore Ts'o
2021-12-31 5:21 ` Dan Cross
2021-12-31 5:55 ` Rob Pike
2021-12-31 13:32 ` Michael Kjörling
2021-12-31 15:53 ` Adam Thornton
2021-12-31 16:13 ` Arthur Krewat
2021-12-31 18:17 ` Dan Cross
2021-12-31 18:23 ` Larry McVoy
2021-12-31 18:37 ` Dan Cross
2021-12-31 18:29 ` Arthur Krewat
2022-01-01 0:09 ` Theodore Ts'o
2022-01-03 13:35 ` Dan Cross
2022-01-03 20:23 ` Theodore Ts'o
2022-01-03 20:45 ` Warner Losh
2022-01-03 21:15 ` Dan Cross
2022-01-03 22:26 ` Theodore Ts'o
2022-01-03 23:10 ` Dan Cross
2022-01-04 15:45 ` Chet Ramey
2022-01-09 19:28 ` Larry McVoy
2022-01-03 23:21 ` Doug McIntyre
2022-01-03 23:37 ` Adam Thornton
2022-01-04 14:49 ` Stuart Remphrey
2022-01-03 23:44 ` Larry McVoy
2022-01-03 23:56 ` [TUHS] SMP: BSD vs System V (once was: moving directories in svr2) Greg 'groggy' Lehey
2022-01-07 19:01 ` Warner Losh
2022-01-09 17:31 ` Stuart Remphrey
2022-01-13 2:35 ` Kevin Bowling
2022-01-03 23:56 ` [TUHS] moving directories in svr2 Warner Losh
2022-01-04 2:28 ` Theodore Ts'o
2022-01-04 2:42 ` Larry McVoy
2022-01-04 9:28 ` [TUHS] Mythical Distress Sale (was Re: moving directories in svr2) Rob Gingell
2022-01-04 15:17 ` Larry McVoy
2022-01-04 15:26 ` arnold
2022-01-04 15:40 ` Larry McVoy
2022-01-04 15:48 ` Richard Salz
2022-01-03 22:57 ` [TUHS] moving directories in svr2 Phil Budne
2022-01-04 15:40 ` [TUHS] VRFs (was Re: moving directories in svr2) Derek Fawcus
2021-12-31 5:12 ` [TUHS] moving directories in svr2 Bakul Shah
-- strict thread matches above, loose matches on Subject: below --
2021-12-29 19:33 Noel Chiappa
2021-12-30 3:40 ` Jay Logue via TUHS
2021-12-29 19:13 Douglas McIlroy
2021-12-29 19:37 ` Dan Cross
2021-12-29 20:15 ` Dan Cross
2021-12-29 20:42 ` Richard Salz
2021-12-29 20:58 ` Dan Cross
2021-12-29 21:20 ` Clem Cole
2021-12-30 3:15 ` Bakul Shah
2021-12-29 17:12 Douglas McIlroy
2021-12-29 16:59 Bakul Shah
2021-12-29 17:04 ` Clem Cole
2021-12-29 17:14 ` arnold
2021-12-29 17:38 ` Clem Cole
2021-12-29 17:49 ` Brantley Coile
2021-12-29 18:27 ` ron minnich
2021-12-29 20:59 ` Rob Pike
2021-12-29 14:33 Will Senn
2021-12-29 15:02 ` arnold
2021-12-29 15:38 ` Will Senn
2021-12-29 15:44 ` Richard Salz
2021-12-29 16:17 ` Clem Cole
2021-12-29 16:58 ` Richard Salz
2021-12-30 5:14 ` Dan Stromberg
2021-12-30 16:22 ` Clem Cole
2021-12-30 18:02 ` John Cowan
2021-12-30 23:04 ` Richard Salz
2021-12-29 15:17 ` Clem Cole
2021-12-29 15:44 ` Will Senn
2021-12-29 16:10 ` Clem Cole
2021-12-29 16:33 ` Warner Losh
2021-12-29 16:01 ` Bakul Shah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKzdPgzOBKEaMdCGxKirP4cxSDeBZrU6VO78JFpxf05vi-5_AQ@mail.gmail.com \
--to=robpike@gmail.com \
--cc=jnc@mercury.lcs.mit.edu \
--cc=tuhs@minnie.tuhs.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).