Hi. This letter is mostly not for Drew himself, but for everybody
else. I hope that Drew's readers will read this mail and will know how
bad Plan 9 actually is.

Plan 9 is not a good OS by modern standards (UNIX-like systems are
not, either). For example, let's consider "mv" util. Here is its Plan
9 (more precisely: 9front) sources:
http://git.9front.org/plan9front/plan9front/30c5296f32b87d83529d772732726891e1261c9c/sys/src/cmd/mv.c/f.html
. As you can see by carefully reading this source, "mv" always
unconditionally COPIES file data (as opposed to Linux: Linux and all
sane OS move files without copying when on the same file system)! I
once asked somewhere (as well as I remember in IRC) why Plan 9 doesn't
have a true mv.

As well as I remember I got this answer: this is because the 9P
protocol (core file protocol in Plan 9) doesn't have move operation.
It doesn't have this operation because of some fundamental reason
related to the beautiful Plan 9 file model. I think this is a very bad
design.

If Plan 9 folks always copy files instead of moving, what can be said
about all other performance-oriented features? I'm nearly sure that
every time Plan 9 authors have a chance to add some
performance-oriented feature, they simply deny it arguing "this will
destroy our nice abstractions". (But if you cannot add
performance-oriented features because of abstractions, it means
something is wrong with your abstractions.)

Now let me move to the next point. Here is a quote from Drew's article:
> Plan 9 is much more Unix in its approach: you open /net/tcp/clone to reserve a connection, and read the connection ID from it. Then you open /net/tcp/n/ctl and write “connect 127.0.0.1!80” to it, where “n” is that connection ID. Now you can open /net/tcp/n/data and that file is a full-duplex stream.

Aaaaaaaah! This is a very bad interface. It is slow, it requires a lot
of syscalls. It requires producing text and then parsing this text at
other side. (And parsing is always error-prone.) This interface
requires user to write "magic" text to "magic" files instead of simply
issuing apropriate syscall. In this video:
https://www.youtube.com/watch?v=9-IWMbJXoLM Rice describes why such
magic files are bad (from 0:00 to 11:00).

Then Drew says:
> No magic syscalls, and you can trivially implement it in a shell script.

????? So Drew thinks that the ability to do TCP from shell script is
somehow a feature? Shell script is one of the worst programming
languages, shell scripts should not be used at all.

-- 
Askar Safin

Quoth Askar Safin <safinaskar@gmail.com>:
> Hi. This letter is mostly not for Drew himself, but for everybody
> else. I hope that Drew's readers will read this mail and will know how
> bad Plan 9 actually is.

I use Plan 9 as my primary personal operating system, and am writing this within it.

> As you can see by carefully reading this source, "mv" always
> unconditionally COPIES file data (as opposed to Linux: Linux and all
> sane OS move files without copying when on the same file system)!

> As well as I remember I got this answer: this is because the 9P
> protocol (core file protocol in Plan 9) doesn't have move operation.

The wstat operation, used to update metadata, can be (and is, in fact, *in the code YOU LINKED*) used as a rename operation.

Renames are supported, but only within the same file system. They're not supported in _every_ case by mv(1) (currently, only within the same folder), but in principle it can be done. The main problem is that it's hard to know if two different folders are on the same file system.

The reality is that it's doable, but nobody has cared enough to make the needed changes, because it _hasn't mattered_. Yes, it's slower - but how often do you move a lot of data to another point on the *same file system*?


- Noam Preil

On Tue Nov 22, 2022 at 1:31 AM UTC,  wrote:
> Renames are supported, but only within the same file system. They're not supported in _every_ case by mv(1) (currently, only within the same folder), but in principle it can be done. The main problem is that it's hard to know if two different folders are on the same file system.

Seems to me that you could just try the fast rename and fall back to a
copy if it fails, what's the reason that doesn't work?

Quoth Ember Sawady <ecs@d2evs.net>:
> On Tue Nov 22, 2022 at 1:31 AM UTC,  wrote:
> > Renames are supported, but only within the same file system. They're not supported in _every_ case by mv(1) (currently, only within the same folder), but in principle it can be done. The main problem is that it's hard to know if two different folders are on the same file system.
> Seems to me that you could just try the fast rename and fall back to a
> copy if it fails, what's the reason that doesn't work?

Imagine you have this directory structure:

foo/
	bar/
	baz/
		a.c

and foo/ is bound over foo/bar, such that foo/bar/baz etc is equal to foo/baz, and the real, on-disk directory foo/bar *cannot* be accessed.

If we tried a rename:

% mv a.c ../bar/a.c

On-disk, the following structure *should* exist:

foo/
	a.c
	bar/
	baz/

However, if we tried renaming - and the fs let us - we'd instead see this:

foo/
	bar/
		a.c
	baz/

mv(1) sees the absolute path, and cannot at present resolve it. With a copy, this does not matter: we go through the kernel to the file system to create the destination, and the kernel resolves the path for us. With a rename, though, it is not aware that we're writing a path at all, so it can't resolve it.

In principle, I think this is solvable. Every process can read its own namespace in /proc/$PID/ns; mv could probably use that to - purely by looking at the list of mount paths - resolve the destination to be fs-local. We could also change the interface to the local mount system (devmnt) to expose it.

This isn't a hard problem, really; it's just not an important one. If you held a gun to my head, I could probably have it solved on my local machine in an hour; getting a solution that would be accepted upstream would probably take longer.


- Noam Preil

Quoth Ember Sawady <ecs@d2evs.net>:
> On Tue Nov 22, 2022 at 1:31 AM UTC,  wrote:
> > Renames are supported, but only within the same file system. They're not supported in _every_ case by mv(1) (currently, only within the same folder), but in principle it can be done. The main problem is that it's hard to know if two different folders are on the same file system.
> Seems to me that you could just try the fast rename and fall back to a
> copy if it fails, what's the reason that doesn't work?

Imagine you have this directory structure:

foo/
	bar/
	baz/
		a.c

and foo/ is bound over foo/bar, such that foo/bar/baz etc is equal to foo/baz, and the real, on-disk directory foo/bar *cannot* be accessed.

If we tried a rename:

% mv a.c ../bar/a.c

On-disk, the following structure *should* exist:

foo/
	a.c
	bar/
	baz/

However, if we tried renaming - and the fs let us - we'd instead see this:

foo/
	bar/
		a.c
	baz/

mv(1) sees the absolute path, and cannot at present resolve it. With a copy, this does not matter: we go through the kernel to the file system to create the destination, and the kernel resolves the path for us. With a rename, though, it is not aware that we're writing a path at all, so it can't resolve it.

In principle, I think this is solvable. Every process can read its own namespace in /proc/$PID/ns; mv could probably use that to - purely by looking at the list of mount paths - resolve the destination to be fs-local. We could also change the interface to the local mount system (devmnt) to expose it.

This isn't a hard problem, really; it's just not an important one. If you held a gun to my head, I could probably have it solved on my local machine in an hour; getting a solution that would be accepted upstream would probably take longer.


- Noam Preil

Ah, gotcha