Re: [TUHS] moving directories in svr2

[Rob Pike <robpike@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4153 bytes --]

Thanks for your thoughtful response (and for reading the paper).

This for me is the catch:

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

And of course you're right, but we've known how to roll out breaking
changes in software for a very long time now. And we do so often. Few Unix
programs from the past would compile and run today without being updated to
"modern" interfaces and compilers.

I believe it could be done, and I believe it should be done. Rolled out
carefully and explained well it would please far more than it offends, and
is arguably far closer to correct than the current situation.

Of course, I am not volunteering, sorry. Easy for me to snipe, I admit, but
then I paid my OS dues long ago.

-rob


On Fri, Dec 31, 2021 at 4:16 PM Theodore Ts'o <tytso@mit.edu> wrote:

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

[-- Attachment #2: Type: text/html, Size: 5038 bytes --]