From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rick Hohensee Message-Id: <200010220013.UAA10279@smarty.smart.net> Subject: Re: [9fans] Df command in Plan9? To: 9fans@cse.psu.edu In-Reply-To: from "Alexander Viro" at Oct 21, 0 06:13:42 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Sat, 21 Oct 2000 20:13:45 -0400 Topicbox-Message-UUID: 1b7b7496-eac9-11e9-9e20-41e7f4b1d025 > > > > On Fri, 20 Oct 100, Rick Hohensee wrote: > > > > > > > > > > > > > On Fri, 20 Oct 2000, Russ Cox wrote: > > > > > > > Please don't tell me that du /dev/sda1 would > > > > do something other than report the disk size > > > > under Linux. > > > > > > > df, BTW, is one of those design flaws of unix that is so > > obvious nobody sees it. A directory has a size. It is the > > size of it's contents, not the size of the "file" containing > > the dirnames and so on. The size of a directory, it's "du-size", > > is something the filesystem should keep track of. > > 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. > * 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 on, which is that the term "design flaw" is an exaggeration. Dyndufs is more like a design 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? > * 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. > * 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. > Punishing all normal processes for the feature they don't > need is Wrong. Moreover, programs that might benefit from that change are > notoriously badly written. I'm yet to see a filemanager that would not be > a bloated pile of crap. If you want to accelerate them - start with > removing the obvious junk, then you might expect at least some sympathy. > > > I had a bag of code hung off the side of Linux for "Dyndufs", > > but then there was a severe ripple in the chrono-synclastic > > infindibulum, and I got a job. > > 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 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. > Due to the reasons above and then some > (semantics on the mountpoints, etc.). IIRC, you just kept repeating that > filemanagers were the only programs that mattered anyway since they are > all that "normal users" (whatever it means) see. Sorry, not impressed. > > Please, who are you talking about? 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. Rick Hohensee 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 / :; www.clienux.com