From: Alexander Viro <viro@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Df command in Plan9?
Date: Sat, 21 Oct 2000 06:13:42 -0400 [thread overview]
Message-ID: <Pine.GSO.4.21.0010210517550.27163-100000@weyl.math.psu.edu> (raw)
In-Reply-To: <200010210037.UAA28304@smarty.smart.net>
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?
* Unices have link(2) and/or bind(2) (I mean Plan 9, not BSD
one). Deal. No, dropping both is not an option.
* you are creating a major contention point, since effects of
_any_ block allocation have to propagate all way down through the
directory tree.
* 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.
* 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. 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. 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.
next prev parent reply other threads:[~2000-10-21 10:13 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-20 20:31 Russ Cox
2000-10-20 21:44 ` Alexander Viro
2000-10-20 21:51 ` Boyd Roberts
2000-10-21 0:37 ` Rick Hohensee
2000-10-21 10:13 ` Alexander Viro [this message]
2000-10-22 0:13 ` Rick Hohensee
2000-10-22 0:25 ` Boyd Roberts
2000-10-22 15:41 ` Rick Hohensee
2000-10-23 9:02 ` Douglas A. Gwyn
2000-10-23 10:30 ` Alexander Viro
2000-10-24 11:37 ` Boyd Roberts
2000-10-25 8:30 ` Douglas A. Gwyn
2000-10-26 4:54 ` Alexander Viro
2000-10-26 5:44 ` Boyd Roberts
2000-10-22 11:34 ` Alexander Viro
2000-10-22 15:59 ` Rick Hohensee
2000-10-22 16:43 ` Alexander Viro
2000-10-23 5:06 ` Boyd Roberts
-- strict thread matches above, loose matches on Subject: below --
2000-10-22 17:06 forsyth
2000-10-23 2:23 ` Rick Hohensee
2000-10-22 11:04 forsyth
2000-10-22 12:49 ` Boyd Roberts
2000-10-22 13:16 ` Alexander Viro
2000-10-22 16:07 ` Rick Hohensee
2000-10-22 16:31 ` Alexander Viro
2000-10-23 2:07 ` Rick Hohensee
2000-10-22 16:05 ` Rick Hohensee
2000-10-20 21:51 presotto
2000-10-20 20:22 Mark C. Otto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.GSO.4.21.0010210517550.27163-100000@weyl.math.psu.edu \
--to=viro@math.psu.edu \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).