Re: [TUHS] moving directories in svr2

["Theodore Ts'o" <tytso@mit.edu>]

On Fri, Dec 31, 2021 at 02:23:15PM +1100, Rob Pike wrote:
> 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

I'm sure it *could* be done.  In fact, Linux has a number of the
pieces of the implementations already, which could be reused for a
Plan-9-style lexical namespace.  Linux has bind mounts, and a dentry is
essentially a cached directory lookup (it contains a pointer to its
parent dentry, the filename used to do the lookup and a pointer to the
resulting inode).  And a struct file contains a struct dentry, which
means in Linux it is possible to determine the path used to open a
particular file.  There are some differences of course; so it's not
exact, but I agree with you that it is quite "doable".  (In
particular, how Linux dentries and symlinks interact appears to be
different from how Plan 9 and Channels did things, if I understand the
paper correctly.)

The question though, is whether Linux *should* do it.  Or rather,
*could* we do it without breaking backwards compatibility with users
and application which expect that dot-dot works the way it does in
classical Unix implementations for the past 4 decades or so.

Granted that the combination of symlinks, and hard links, and in
Linux, bind mounts (not to mention bind namespaces, chroots, and
pivot_root operations), can be confusing.  But there is a whole
ecosystem of shell scripts, programs, user's finger macros, etc., that
would break if we "made things better" or "made things simpler".

One of the benefits of research OS's is that you can experiment with
things without having to worry about the howls of angry users when you
break backwards compatibility, or eliminate some particular awkward
API or feature.

      	      	   	       	     	   - Ted

P.S.  For example, how I wish I could eliminate telldir/seekdir, or at
least change things so that telldir/seekdir used a substantially
larger "cookie" to memoize a position in a directory's readdir stream
which has to be valid effectively forever.  Today, you can pass a
32-bit telldir cookie to seekdir, and readdir MUST not return a
directory entry that it had already returned, and MUST not skip a
directory entry that was present at the time of the telldir().  Thus
spake POSIX, and there are applications which depend on
telldir/seekdir/readdir having this precise set of semantics

If your directory is stored internally as a linear stream, that's not
too bad; but if you're using a more complex data structure, life gets
interesting.  I know of one file system (JFS) which added an extra,
separate, on-disk b-tree structure to each directory just to be able
to provide stable telldir/seekdir cookies.  (And of course, there's a
performance impact to needing to update an extra b-tree each time a
directory entry is added or removed.)

With a research OS, it's at least possible to say, "Well, *that* was a
mistake; let's pretend it never happened and let's see how much better
life would be."  :-)