Re: [9fans] Df command in Plan9?

Re: [9fans] Df command in Plan9?

[Russ Cox]

Look in the archives -- I and someone else (tad?)
have posted df scripts/programs for kfs.  Mine is
at www.eecs.harvard.edu/~rsc/plan9.html.

mount /srv/kfs /n/kfs
du /n/kfs | tail

will get you the number you're looking for.
du '#SsdC0' will produce a number but likely
not the one you want.  Du just sums the sizes
of all the files it sees.

Please don't tell me that du /dev/sda1 would
do something other than report the disk size
under Linux.

Russ

Re: [9fans] Df command in Plan9?

[Alexander Viro]

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.

??? du(1) does lstat(2), notices that thing is not a directory and
prints (scaled) st_blocks. In case of device inode it's 0, plain and
simple.

% du /dev/sda1
0	/dev/sda1
% uname
Linux

Same happens on many other Unices. Damn in I remember how old versions
acted (IIRC non-directory would be ignored/flamed), but I've never seen
one that would print the device size.

I've definitely never heard of du(1) on device doing an equivalent of
df(1) - for one thing, it would require ability to guess the filesystem
type and parse the superblock. Even GNU didn't try _that_ feature.

Re: [9fans] Df command in Plan9?

[Boyd Roberts]

From: Alexander Viro <viro@math.psu.edu>
To: <9fans@cse.psu.edu>
Sent: Friday, October 20, 2000 11:44 PM
Subject: Re: [9fans] Df command in Plan9?


>
> I've definitely never heard of du(1) on device doing an equivalent of
> df(1) - for one thing, it would require ability to guess the filesystem
> type and parse the superblock. Even GNU didn't try _that_ feature.

du works on plain files and directory trees.

df works on file-systems.

Re: [9fans] Df command in Plan9?

[Rick Hohensee]

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

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.

I wonder what X, GNOME, Enlightenment, Perl and so on would
look like if the developers of them were constantly seeing the
size results of thier actions.

Rick Hohensee

Re: [9fans] Df command in Plan9?

[Alexander Viro]

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.

Re: [9fans] Df command in Plan9?

[Rick Hohensee]

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

Re: [9fans] Df command in Plan9?

[Boyd Roberts]

From: Rick Hohensee <humbubba@smarty.smart.net>

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

oh nonsense.  directories are the size of their meta-data.

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

this is exactly the problem with linux; everything is a 'design opportunity'.
it's never ending and has not advanced the state of the art by one iota.

>
> True. When was the last time you did a du on / ? Or /usr ? Why?
>

not for a while, but when i needed to tar up a tree on multiple floppies
i used du, before invoking tar.  i see that SCO broke tar so it would
know about multiple volumes.  i wrote a script.  it's called a 'tools
approach'.

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

kirk said that it took multiple iterations to get rename(2)
right, because it's a nasty problem.

Re: [9fans] Df command in Plan9?

[Rick Hohensee]

>
> From: Rick Hohensee <humbubba@smarty.smart.net>
>
> > > > 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.
>
> oh nonsense.  directories are the size of their meta-data.

Remove one and see if your df changes by the size of the metadata.


>
> > 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.
>
> this is exactly the problem with linux; everything is a 'design opportunity'.
> it's never ending and has not advanced the state of the art by one iota.
>

This is exactly not Linux. This is _not_ "giving a paper" on something in the
Bach book as if it was a new concept.

Rick Hohensee

Re: [9fans] Df command in Plan9?

[Douglas A. Gwyn]

Boyd Roberts wrote:
> kirk said that it took multiple iterations to get rename(2)
> right, because it's a nasty problem.

How could it be?  It's just modifying a record in a single
file (the directory file).  I understand that organizing
that file as variable-length records makes updating a problem,
but rename as such is easy (lock, change, unlock).

Re: [9fans] Df command in Plan9?

[Alexander Viro]

On Mon, 23 Oct 2000, Douglas A. Gwyn wrote:

> Boyd Roberts wrote:
> > kirk said that it took multiple iterations to get rename(2)
> > right, because it's a nasty problem.
>
> How could it be?  It's just modifying a record in a single
> file (the directory file).  I understand that organizing
> that file as variable-length records makes updating a problem,
> but rename as such is easy (lock, change, unlock).

rename() can move stuff from one directory to another. Morever, if the
source is a directory, target exists and is an empty directory you
get the target killed. Trust me, it _is_ hell to do right - BTDT, got
nightmares.

Subset implemented in Plan 9 is very easy compared to that. You can't
change the topology, you don't have to lock both parents, you don't have
to lock the victim to avoid races between check for emptiness and creation
of objects in it, you don't have to bother with check for loop-creation
_and_ with races between rename("/a/a","/b/b/b/b") and
rename("/b/b","/a/a/a/a") (each legal, together they create a loop)

It was a living hell. And Kirk didn't get it right in 4.4, BTW -
it was vulnerable to rename/rename race. Variant in Linux seems to be
provably correct (as always, modulo correctness of translation into the
model), but it's not pretty (triple_down() - 'nuff said). Check fs/namei.c
in 2.4 - vfs_rename() and sys_rename() do the thing. And it's still the
place where we have to do very heavy-hand SMP locking - rules for access
to ->d_parent and d_move() are seriously complicated by that crap.

Constant vs. variable-size records have nothing with that. Real problems
are fs-independent.

Re: [9fans] Df command in Plan9?

[Boyd Roberts]

From: Douglas A. Gwyn <DAGwyn@null.net>

> Boyd Roberts wrote:
> > kirk said that it took multiple iterations to get rename(2)
> > right, because it's a nasty problem.
>
> How could it be?  It's just modifying a record in a single
> file (the directory file).  I understand that organizing
> that file as variable-length records makes updating a problem,
> but rename as such is easy (lock, change, unlock).

i'm suprised by this response from you, doug.  the wdir
is the least of the problem(s).  it's working out whether
you're ripping out the tree from under yourself is the
nasty problem.  or, maybe for you, kernel n-ary tree
structure mangling is a simple operation.

Re: [9fans] Df command in Plan9?

[Douglas A. Gwyn]

Boyd Roberts wrote:
> ... it's working out whether
> you're ripping out the tree from under yourself is the
> nasty problem.

But that's a move, not a rename.

Re: [9fans] Df command in Plan9?

[Alexander Viro]

On Wed, 25 Oct 2000, Douglas A. Gwyn wrote:

> Boyd Roberts wrote:
> > ... it's working out whether
> > you're ripping out the tree from under yourself is the
> > nasty problem.
>
> But that's a move, not a rename.

rename(2) in 4.2BSD and other Unices that picked/inherited it _is_ move.
Yes, it's overcomplicated, it sucks badly wrt required locking, it has
extremely nasty potential for races with rmdir() and itself, yodda, yodda.
I have no idea why Kirk went for that horror. He did. Once it works right
it's a convenient thing to have around, but getting it work right...
<shudder> Apologies for self-quoting, but...
/*
 * The worst of all namespace operations - renaming directory. "Perverted"
 * doesn't even start to describe it. Somebody in UCB had a heck of a trip...
 * Problems:
 *      a) we can get into loop creation. Check is done in is_subdir().
 *      b) race potential - two innocent renames can create a loop  together.
 *         That's where 4.4 screws up. Current fix: serialization on
 *         sb->s_vfs_rename_sem. We might be more accurate, but that's another
 *         story.
 *      c) we have to lock _three_ objects - parents and victim (if it exists).
 *         And that - after we got ->i_sem on parents (until then we don't know
 *         whether the target exists at all, let alone whether it is a directory
 *         or not). Solution: ->i_zombie. Taken only after ->i_sem. Always taken
 *         on link creation/removal of any kind. And taken (without ->i_sem) on
 *         directory that will be removed (both in rmdir() and here).
 *      d) some filesystems don't support opened-but-unlinked directories,
 *         either because of layout or because they are not ready to deal with
 *         all cases correctly. The latter will be fixed (taking this sort of
 *         stuff into VFS), but the former is not going away. Solution: the same
 *         trick as in rmdir().
 *	[ the latter had been fixed, the former == NFS and SMBFS these days ]
 *      e) conversion from fhandle to dentry may come in the wrong moment - when
 *         we are removing the target. Solution: we will have to grab ->i_zombie
 *         in the fhandle_to_dentry code. [FIXME - current nfsfh.c relies on
 *         ->i_sem on parents, which works but leads to some truely excessive
 *         locking].
 */
int vfs_rename_dir(struct inode *old_dir, struct dentry *old_dentry,
               struct inode *new_dir, struct dentry *new_dentry)
{
        int error;
        struct inode *target;

        if (old_dentry->d_inode == new_dentry->d_inode)
                return 0;

        error = may_delete(old_dir, old_dentry, 1);
        if (error)
                return error;

        if (new_dir->i_dev != old_dir->i_dev)
                return -EXDEV;

        if (!new_dentry->d_inode)
                error = may_create(new_dir, new_dentry);
        else
                error = may_delete(new_dir, new_dentry, 1);
        if (error)
                return error;

        if (!old_dir->i_op || !old_dir->i_op->rename)
                return -EPERM;

        /*
         * If we are going to change the parent - check write permissions,
         * we'll need to flip '..'.
         */
        if (new_dir != old_dir)
                error = permission(old_dentry->d_inode, MAY_WRITE);
        if (error)
                return error;

        DQUOT_INIT(old_dir);
        DQUOT_INIT(new_dir);
        down(&old_dir->i_sb->s_vfs_rename_sem);
        error = -EINVAL;
        if (is_subdir(new_dentry, old_dentry))
                goto out_unlock;
        target = new_dentry->d_inode;
        if (target) { /* Hastur! Hastur! Hastur! */
                triple_down(&old_dir->i_zombie,
                            &new_dir->i_zombie,
                            &target->i_zombie);
                d_unhash(new_dentry);
        } else
                double_down(&old_dir->i_zombie,
                            &new_dir->i_zombie);
        if (IS_DEADDIR(old_dir)||IS_DEADDIR(new_dir))
                error = -ENOENT;
        else if (d_mountpoint(old_dentry)||d_mountpoint(new_dentry))
                error = -EBUSY;
        else
                error = old_dir->i_op->rename(old_dir, old_dentry,
					      new_dir, new_dentry);
        if (target) {
                if (!error)
                        target->i_flags |= S_DEAD;
                triple_up(&old_dir->i_zombie,
                          &new_dir->i_zombie,
                          &target->i_zombie);
                if (d_unhashed(new_dentry))
                        d_rehash(new_dentry);
                dput(new_dentry);
        } else
                double_up(&old_dir->i_zombie,
                          &new_dir->i_zombie);

        if (!error)
                d_move(old_dentry,new_dentry);
out_unlock:
        up(&old_dir->i_sb->s_vfs_rename_sem);
        return error;
}

... and that's just the directory-specific part of VFS side of the thing,
after we got i_sem on parents and got dentries of source and target.
->i_op->rename() does fs-dependent part of work.

Full-blown rename() is painful, just as full-blown truncate() and correct
handling of symlinks. Nice to have on the userland side of things, but
kernel side is something. truncate()/mmap()/write() alone makes for a
serious S&M shop.

Re: [9fans] Df command in Plan9?

[Boyd Roberts]

From: Alexander Viro <viro@math.psu.edu>

> On Wed, 25 Oct 2000, Douglas A. Gwyn wrote:
>
> > Boyd Roberts wrote:
> > > ... it's working out whether
> > > you're ripping out the tree from under yourself is the
> > > nasty problem.
> >
> > But that's a move, not a rename.
>
> rename(2) in 4.2BSD and other Unices that picked/inherited it _is_ move.

yes, that's what i was referring to.

Re: [9fans] Df command in Plan9?

[Alexander Viro]

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

Re: [9fans] Df command in Plan9?

[Rick Hohensee]

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

Ah, there's the problem. I keep trying to think, in most un-unix-like fashion,
that a user is somehow more important than a process.


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

Heh. Lets see you rename everything but /dev and install ncurses. Hint: ed .

After attempting the above, and subsequently re-installing Mandrake, you can
grep l-k for DSFH or Dotted Standard File Hierarchy.

Who?

Re: [9fans] Df command in Plan9?

[Alexander Viro]

On Sun, 22 Oct 100, Rick Hohensee wrote:

> > > 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...
>
> Ah, there's the problem. I keep trying to think, in most un-unix-like fashion,
> that a user is somehow more important than a process.

Rick, remember the comment about demagogy? That's precisely what I was
refering to. s/process/operation requested by user/ and reread the
sentence you've quoted. IMO you've missed your calling - in marketing or
election campaigns your lack of intellectual honesty would be really
great, but for fsck sake, stay away from the technical stuff, you are only
making yourself look pathetic.

Re: [9fans] Df command in Plan9?

[Boyd Roberts]

From: Rick Hohensee <humbubba@smarty.smart.net>

> Ah, there's the problem. I keep trying to think, ...

that, about, says it all.

Re: [9fans] Df command in Plan9?

[forsyth]

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

thank you.  i suppose the .renamin technique was adopted to allow
patching binaries.  to draw things back to plan 9,
i thought the following rule was interesting:

``for a binary to expect a file at a specific full pathname is bad practice.''

curiously, that is regarded as standard practice and
perhaps even essential for both Plan 9 and Inferno.
o tempora, o mores!


[-- Attachment #2: Type: message/rfc822, Size: 2095 bytes --]

From: Rick Hohensee <humbubba@smarty.smart.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Df command in Plan9?
Date: Sun, 22 Oct 100 12:05:44 -0400 (EDT)
Message-ID: <200010221605.MAA11584@smarty.smart.net>

>
> >>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 didn't understand this bit.
>
>

   Linkname: seedoc of the Dotted Standard Filename Hierarchy
        URL: ftp://linux01.gwdg.de/pub/cLIeNUX/descriptive/DSFH.html
       size: 251 lines

Rick Hohensee

Re: [9fans] Df command in Plan9?

[Rick Hohensee]

>
> This is a multi-part message in MIME format.
> --upas-ohokjsaitbekiuklfrxnjnkvqz
> Content-Disposition: inline
> Content-Type: text/plain; charset="US-ASCII"
> Content-Transfer-Encoding: 7bit
>
> thank you.  i suppose the .renamin technique was adopted to allow
> patching binaries.  to draw things back to plan 9,
> i thought the following rule was interesting:

Yes. A simple ed script can convert almost anything. X server source
eludes my script because it has a /name in it somewhere, and I stick
to looking for /name/ . So I edit XFree server bins by hand. There are
other wrinkles here and there, but for the most part it was surprisingly
easy to convert. If I ever get another cLIeNUX out the .names will be the
real dirs, and the symlinks will be the visible names. Then you can just
mv command bin   if you like.

>
> ``for a binary to expect a file at a specific full pathname is bad practice.''
>
> curiously, that is regarded as standard practice and
> perhaps even essential for both Plan 9 and Inferno.
> o tempora, o mores!
>

Well, it's all subjective. Note that I didn't mess with /dev   :o)

Thanks for asking, BTW.

Rick Hohensee

Re: [9fans] Df command in Plan9?

[forsyth]

>>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 didn't understand this bit.

Re: [9fans] Df command in Plan9?

[Boyd Roberts]

From: <forsyth@caldo.demon.co.uk>

> >>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 didn't understand this bit.

neither did i, but it wouldn't be linux without _two_ execve's.

:-)

Re: [9fans] Df command in Plan9?

[Alexander Viro]

On Sun, 22 Oct 2000 forsyth@caldo.demon.co.uk wrote:

> >>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 didn't understand this bit.

IIRC, Rick wanted to get rid of /sbin (such an unfriendly name, you see),
so he had renamed it (in his forked variant) to /.<something> (.sbi? bugger
if I remember). Well, since kernel does exec() on /sbin/init he added one
more attempt to serve his setup. So far so good (you fork the tree, you
get to change whatever you want, after all). Well, he asked to put that
patch into the main tree and had been asked WTF did he need it. Major
whining followed (blah, blah, blah, cryptic directory names, blah, blah,
user-unfriendly, blah, I want it in the main tree, ....). The bottom
line was that he had been politely told to sod off and stop wanking.
Considering the fact that boot loader can pass "init=<pathname>" to the
kernel and that will give exactly what he was asking for...

Re: [9fans] Df command in Plan9?

[Rick Hohensee]

>
>
>
> On Sun, 22 Oct 2000 forsyth@caldo.demon.co.uk wrote:
>
> > >>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 didn't understand this bit.
>
> IIRC, Rick wanted to get rid of /sbin (such an unfriendly name, you see),
> so he had renamed it (in his forked variant) to /.<something> (.sbi? bugger
> if I remember). Well, since kernel does exec() on /sbin/init he added one
> more attempt to serve his setup. So far so good (you fork the tree, you
> get to change whatever you want, after all). Well, he asked to put that
> patch into the main tree and had been asked WTF did he need it. Major
> whining followed (blah, blah, blah, cryptic directory names, blah, blah,
> user-unfriendly, blah, I want it in the main tree, ....). The bottom
> line was that he had been politely told to sod off and stop wanking.
> Considering the fact that boot loader can pass "init=<pathname>" to the
> kernel and that will give exactly what he was asking for...
>
>

What bootloader?

Rick Hohensee

Re: [9fans] Df command in Plan9?

[Alexander Viro]

On Sun, 22 Oct 100, Rick Hohensee wrote:

> > Considering the fact that boot loader can pass "init=<pathname>" to the
> > kernel and that will give exactly what he was asking for...
>
> What bootloader?

The thing that brings the kernel image in core. LILO, GRUB, whatever you
fancy. And RTFM, already.

Re: [9fans] Df command in Plan9?

[Rick Hohensee]

>
>
>
> On Sun, 22 Oct 100, Rick Hohensee wrote:
>
> > > Considering the fact that boot loader can pass "init=<pathname>" to the
> > > kernel and that will give exactly what he was asking for...
> >
> > What bootloader?
>
> The thing that brings the kernel image in core. LILO, GRUB, whatever you
> fancy. And RTFM, already.
>
>

cp a bzImage to a floppy. I boot from such a floppy at work to keep
W2k and the large young sysadmin out of my hair. No bootloader, per se.

You're really quite spaced out Al. Take a breather. Go for a walk.

Rick Hohensee

Re: [9fans] Df command in Plan9?

[Rick Hohensee]

>
> >>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 didn't understand this bit.
>
>

   Linkname: seedoc of the Dotted Standard Filename Hierarchy
        URL: ftp://linux01.gwdg.de/pub/cLIeNUX/descriptive/DSFH.html
       size: 251 lines

Rick Hohensee

Re: [9fans] Df command in Plan9?

[presotto]

what about

	disk/kfscmd check

It takes a while since it's more like fsck but you get
your answer:

checking file system: main
check free list
lo = 8155; hi = 412499
   11417 files
  412499 blocks in the file system
   87267 used blocks
  325232 free blocks
   15658 maximum qid path

[9fans] Df command in Plan9?

[Mark C. Otto]

Having a 500mb disk drive, I was looking to check how much disk space I had
left.  I haven't been able to find an equivalent of the unix df command to find
the space used and available,

df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/sda5              4546016   1650964   2664120  38% /
/dev/sda2                23333      6149     15980  28% /boot
/dev/sda1              2036224   1819008    217216  89% /mnt/win
/dev/sdb1              8947440   2234552   6712888  25% /mnt/win2
parula:/data           8124357   7013836   1029278  87% /mnt/parula/data
parula:/space          1372362   1155507    161961  88% /mnt/parula/space
/dev/fd0                  1423      1252       171  88% /mnt/floppy

Du on a device does not even get at the space used,

du #sdC0

For a terminal, I would have expected something in disk/kfscmd.  For the
fileserver, am I missing something in fs(8)?

Thanks,
Mark