[9fans] fidtab revisited

[9fans] fidtab revisited

[Andrew Simmons]

Pondering further on fidtab, I was wondering if anyone had any statistics on
the average and maximum number of fids in the table for any given connection
to u9fs. Since a hash table was considered appropriate, I would guess that
quite a few fids were anticipated, but since the current implementation is
effectively a linked list, I would also guess that there are not that many
in practice. My interest in this is that I'm tooling around with a knock-off
of u9fs running as an NT service serving NT files, mainly as an exercise to
nail down my understanding of how 9p works.

On a slightly related note, ever since reading "The Practice of
Programming", I had vaguely assumed that the pack and unpack routines in
chapter 9 were derived from 9p, but on reading the Plan 9 code it appears
that the marshalling and unmarshalling work is done by a number of
preprocessor macros. I'd be interested to know, if it's not confidential,
where pack and unpack are actually in use, and also why they aren't used in
Plan 9.

And finally. Dan Cross, get back to bed and take some paracetamol and get a
good night's sleep, or I'll ask Jim Choate to go to St. Petersburg with you
as an interpreter.

Re: [9fans] fidtab revisited

[rob pike, esq.]

Pack and unpack were freshly written for the book.

-rob

Re: [9fans] fidtab revisited

[Russ Cox]

Pack and unpack were inspired by my 1998 attempts
at writing an SMB client for Plan 9.  The packets are
these grotesque little blobs that have a certain amount
of reason to them internally but not enough to make it
easy to parse.  The little mini-language made the code a lot
shorter but in the end, a lot harder to understand and debug.
I've since tossed it out and written traditional packet
routines, though even that hasn't been enough to salvage
the project (yet).

The minilanguage for smb was nice mainly because there
are redundant count fields scattered throughout
the packet, and the assembler takes care of those automatically.

9P doesn't really need a packet assembler because things are
so simple.  The packet assembler would be just as long
as the simple implementation.  There's also something therapeutic
about how direct that code is.  (I've been playing with an
Sun RPC compiler recently; trust me on this.)

Here are some examples from the 1998 SMB code.  The #
separates request from reply formats.  Inside each half,
the | separates the "word" section from the "data" section.
of the packet.  *X and *D variable sized data in various
guises.  A appears to be a string.

Russ


static int
PCsession(void)
{
	ushort action;
	int l;

	l = strlen(smb.passwd);
	if(dosmb(SmbSessionX, Niltid, 1, "hhhhhlhl|*Xaaaa#hhh|",
		0xff, 0, 7000, 1, 0, 0, l,
		0, l, smb.passwd, "rsc", "rsc-land", "plan9", "plan9",
		nil, nil, &action) < 0)
		return -1;
	chat("action=%x...", action);
	return 0;
}

static int
PCtreecon(char *tree)
{
	ushort tid;
	char str[1024];
	smb.tree = strdup(tree);	/* FIXME */
	snprint(str, sizeof str, "\\\\%s\\%s", smb.servername, tree);
	strupr(str);

	chat("treecon(%s)...", str);
	if(dosmb(SmbTreeConn, Niltid, 1, "|AAA#hh|", str, smb.passwd, "A:", nil, &tid) < 0)
		return -1;
	return tid;
}

static int
PCopen(char *fname, int mode)
{
	char str[1024];
	int fd;

	mode = (4<<4)|mode;	/* no locking */
	snprint(str, sizeof str, "%s", fname);	/* FIXME XXX estrdup */
	strupr(str);

	chat("\nopen(%s, 0x%x)...", str, mode);
	if(dosmb(SmbOpen, smb.tid, 1, "hh|A#hhllh|", mode, 0, str, &fd, nil, nil, nil, nil) < 0)
		return -1;
	return fd;
}

static int
PCread(int fd, void *v, int off, int n)
{
	if(dosmb(SmbRead, smb.tid, 1, "hhlh|#hll|*D", fd, n, off, 0, nil, nil, nil, &n, v) < 0)
		return -1;
	return n;
}

static int
PCwrite(int fd, void *v, int off, int n)
{
	if(dosmb(SmbWrite, smb.tid, 1, "hhlh|*D#h|", fd, n, off, 0, n, v, &n) < 0)
		return -1;
	return n;
}

static int
PCcreate(char *fname, int mode, int perm)
{
	int t, fd;

	USED(mode);
	t = time(0);
	perm = (perm & 0200) ? 0x20: 0x21;
	if(dosmb(SmbCreate, smb.tid, 1, "hl|A#h|", perm, t, fname, &fd) < 0)
		return -1;
	return fd;
}

Re: [9fans] fidtab revisited

[Ronald G. Minnich]

On Mon, 17 Feb 2003, Andrew Simmons wrote:

> Pondering further on fidtab, I was wondering if anyone had any statistics on
> the average and maximum number of fids in the table for any given connection
> to u9fs. Since a hash table was considered appropriate, I would guess that
> quite a few fids were anticipated, but since the current implementation is
> effectively a linked list, I would also guess that there are not that many
> in practice. My interest in this is that I'm tooling around with a knock-off
> of u9fs running as an NT service serving NT files, mainly as an exercise to
> nail down my understanding of how 9p works.


On v9fs on Linux, once the dcache came into the picture, we found fid use
increased to the hundreds, pretty much to the sum of all files opened for
the uptime of the machine, until such time as resources were needed.  We
capped fids at 256 to test our code for handling "out of fids" on the
client (v9fs) side, and there we ran into an interesting problem.  Linux
dcache entry flushing is pretty primitive: you pretty much say 'flush all
them there dcache entries for the superblock' and they all go away
(preferable would be something SunOS did in some areas, which was to say
'try to flush 100 or so of "this thing"' but maybe Linux will improve in
that area).

Since we almost have the 9p2000 client working on linux now, I expect to
get these numbers for u9fs -- I'll let you know.

ron