9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: G. David Butler gdb@dbSystems.com
Subject: [9fans] allowing long file names with a space too
Date: Tue, 14 Apr 1998 10:05:08 -0500	[thread overview]
Message-ID: <19980414150508.HLihI7RavBt-b-a7es41tiywoorE7CDMo5yUQ9Ukp5g@z> (raw)

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




             reply	other threads:[~1998-04-14 15:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-04-14 15:05 G.David [this message]
  -- strict thread matches above, loose matches on Subject: below --
1998-04-14  9:56 Elliott.Hughes
1998-04-14  9:52 Elliott.Hughes
1998-04-10 23:16 G.David

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=19980414150508.HLihI7RavBt-b-a7es41tiywoorE7CDMo5yUQ9Ukp5g@z \
    --to=9fans@9fans.net \
    /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).