[9fans] allowing long file names with a space too

[9fans] allowing long file names with a space too

[Elliott.Hughes]

> Tclwalk tag[2] fid[2] newfid[2] name[<=256]
> Twalk tag[2] fid[2] name[<=256]
> Tcreate tag[2] fid[2] name[<=256] perm[4] mode[1] [move name to the end?]
> Rstat tag[2] fid[2] stat[<=344]
> Twstat tag[2] fid[2] stat[<=344]
> 
> [why is there a pad[1] in Twrite and Rread?]

So that 1 + 2 + 2 + 2 + 1 = 8 in Rread's case, and
1 + 2 + 2 + 8 + 2 + 1 = 16 in Twrite's? This puts the data on
a nice boundary (assuming that the message was aligned).

-- 
http://users.ch.genedata.com/~enh/

[9fans] allowing long file names with a space too

[G.David]

From: Elliott.Hughes@genedata.com

>So why bother with an upper limit on length at all? Why trade one
>hard-coded assumption for another? Because you're implementing
>some specific protocol?

Good point.  Because of stat/wstat the limit is MAXFDATA(8192)-88=8104
unless you include the 88 octets as part of the header.

The biggest problem with ~8k file names is practical limits of
implementations.  For example, after staring a while at calculations
of the wasted disk space that results from allocating name[256] when
most names will fit in 64 (21 unicode characters), I thought a limit
of 64 would be OK :-<.  256-64 = 192 * 6 million files = 1.1 Gigabyte,
and if only 10 are used most of the time then it is 1.5 GB wasted.

Wow.

In defense, I came up with a design for variable length file names
in the file server that limit the largest name to BUFSIZE, or 4088
octets with RBUFSIZE set to 4096.  My system doesn't expect many files
over 1k so my RBUFSIZE is 1024 (yes, I added triple indirects) and
the file name limit is 1016.

Now that 9P can support file names up to 8104 octets (including the
NULL), and the fileserver will support names that depend on tuning,
what is the best way for a server to interact with 9P?

I think a Tcreate/Twstat that has a name too long for the server
should return Enamelen "create/wstat -- file name too long".

David Butler
gdb@dbSystems.com

[9fans] allowing long file names with a space too

[Elliott.Hughes]

> The idea is to only send the variable data in 9P, so the
> "machine independent encoding" stays fixed length.  The mount
> driver will do the "right thing".

So why bother with an upper limit on length at all? Why trade one
hard-coded assumption for another? Because you're implementing
some specific protocol?

-- 
http://users.ch.genedata.com/~enh/

[9fans] allowing long file names with a space too

[G.David]

From: "G. David Butler" <gdb@dbSystems.com>

>NAMELEN = 28
>FNAMELEN = 64? 128? 256!?  Hell, might as well fix it now. 256.
>
>In that case the overhead for 9p now gets quite high given all
>the Twalks.  So how about a uchar length followed by data?  Makes
>sense.

Lets say that FNAMELEN = 256 then:

DIRLEN = 344

Tclwalk tag[2] fid[2] newfid[2] name[<=256]
Twalk tag[2] fid[2] name[<=256]
Tcreate tag[2] fid[2] name[<=256] perm[4] mode[1] [move name to the end?]
Rstat tag[2] fid[2] stat[<=344]
Twstat tag[2] fid[2] stat[<=344]

[why is there a pad[1] in Twrite and Rread?]

The idea is to only send the variable data in 9P, so the
"machine independent encoding" stays fixed length.  The mount
driver will do the "right thing".  In other words, since
names must terminate with a null '\0', in 9P there will only
be one.  It is the mnt driver's responsibility to transmit
the Twstat and receive Rstat and directory Tread/Twrite that way.

On directory read, the mount driver will have to muck with
the offsets since they must be 0 mod DIRLEN.  On Tread the offset
and count will be 0 mod DIRLEN but the server will respond with
the real count of the packet.  The mnt driver will expand the names
and set the offset for the channel so the next Tread will work.
This is permissable already (see devdirread() in /sys/src/9/port/dev.c
and the comment in /sys/src/9/port/sysfile.c).  I use it now to allow
efficient reads of the large directories on my file server by
eliminating the silly "count the filled slots" algorithm.  (You see,
only the mnt driver knows the proper offsets for the channel.)

We could add count[2] to the above messages, but I don't think
that is necessary.

It's too bad that Tcreate didn't have the name at the end, then the
resulting kernel would be backward compatable with existing servers. :-(

Comments?  (the ones that look like "your crazy" to /dev/null)

David Butler
gdb@dbSystems.com