Re: [9fans] Df command in Plan9?

[Alexander Viro <viro@math.psu.edu>]

On Sat, 21 Oct 100, Rick Hohensee wrote:

> > Sigh... Rick, we've been through that how many times?
>
> Who's "we"? I don't recall mentioning this here. You and I haven't
> been over this at all that I recall. I did have some considered criticism
> of this in comp.unix.programmer, where a regular there breached the name
> Dyn-du.

grep l-k archives.

> > 	* Unices have link(2) and/or bind(2) (I mean Plan 9, not BSD
> > one). Deal. No, dropping both is not an option.
>
> This drops nothing. This points up the one thing you SHOULD have called me

Then WTF _is_ "directory that contains file"? And how the green fsck do
you find all parents? Full scan of the tree? And let's not go into the
sweet effects of mountpoint located on r-o filesystem. Or, better yet,
several processes having different sets of bindings.

> on, which is that the term "design flaw" is an exaggeration. Dyndufs is
> more like a design opportunity.

"We've met an insurmountable opportunity"...

> > 	* you are creating a major contention point, since effects of
> > _any_ block allocation have to propagate all way down through the
> > directory tree.
>
> True. When was the last time you did a du on / ? Or /usr ? Why?

Exactly. So you are giving performance problems to normal processes just
to make the operation of _really_ dubious merit run faster. Once in many
months. Smart, that...

> > 	* Forget about the metadata consistency - with your scheme damn
> > next to every operation requires multiple on-disk changes, and that's
> > putting it quite mildly.
>
> The "on-disk" part is subject to some variation.

As in "we get a dirty shutdown and fs consistency, erm, varies"?

> > 	* Non-local operations are prone to races. Even cross-directory
> > rename(2) is a major PITA. The thing you are proposing is going to be
> > much worse.
> > 	* Programs that might benefit from that "du-size" are either
> > going to scan the tree anyway or belong to very small class -
> > filemanagers.
>
> You've just promoted ls to a filemanager. How Microsoftian.

Since when does ls(1) need your "du-size" to work?

> > You've also been told that these changes are _not_ going into the tree,
> > *period*. Quite a few times.
>
> What tree? Perhaps the thing to do is just point me at whoever it is you

ftp.kernel.org one. _Any_ form of that "let's count the sizes of all
objects refered from directory" is out.

> are confusing me for, if this stuff already exists. The stuff I did was
> just at the level of "yes, this is using the VFS headers to initialize all
> this callback nonsense", and this is the first I've mentioned the "code"
> anywhere.

Irrelevant. The thing is broken by design and reasons had been discussed
quite a few times. Period. You want to play with that bogosity - you fork
the tree.

> BTW, the stuff I HAVE basically silently been informed won't be going into
> the Linus Linux tree is my stuff to support booting to /.sbi/init so that
> the dirnames the user sees can be internationalized or otherwise
> localized. 2 execve's in init/main.c. I also am unimpressed. I have since
> found out that cLIeNUX, my little distro, is in some ways the very poor
> man's Plan9. No WONDER a trivial little patch for 5 billion people went
> ignored. NIH. I look for outlets for good ideas. I looked in l-k. I'm
> still looking.

<wry>
You might need a good idea first. Cutting down on demagogy might help too.
</wry>

> this Rick Hohensee...
> :; cLIeNUX0 /dev/tty3  18:01:03   /
> :;d
> ABOUT        LGPL         command      floppy       mounts       suite
> ABOUT.Linux  Linux        configure    guest        owner        temp
> CD           RIGHTS       dev          help         source
> GPL          boot         etc          log          subroutine
> :; cLIeNUX0 /dev/tty3  18:01:06   /

<shrug> So you can make gratitious changes to directory names. Maybe
you've even mastered sed(1). Wow...