From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <0fd845b9ba300f41b4f0607ede960285@lyons.quanstro.net> References: <96413B2B-5F5B-4C27-B2B5-483FB9B811D2@ar.aichi-u.ac.jp> <0fd845b9ba300f41b4f0607ede960285@lyons.quanstro.net> Date: Sun, 23 Jun 2013 14:59:52 -0700 Message-ID: From: Skip Tavakkolian To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e0149cd4a645d6a04dfd96aba Subject: Re: [9fans] long filenames in cwfs Topicbox-Message-UUID: 67ade722-ead8-11e9-9d60-3106f5b1d025 --089e0149cd4a645d6a04dfd96aba Content-Type: text/plain; charset=ISO-8859-1 with 8K names, using base64, one could encode 6111 bytes of data in the name. i just did a quick inventory[*] of my $home; 74% of my files have less than 6112 bytes of data. [*] % fn pctfileslessthan6k () { x=`{du -na $home|wc -l} y=`{du -na $home|awk '$1 < 6112 {print $0}'|wc -l} pct=`{echo '2k ' $y $x ' / 100 * p' | dc} echo $pct } % pctfileslessthan6k 74.00 % On Sun, Jun 23, 2013 at 7:08 AM, erik quanstrom wrote: > On Sun Jun 23 09:38:01 EDT 2013, arisawa@ar.aichi-u.ac.jp wrote: > > Thank you cinap, > > > > I tried to copy all my Dropbox data to cwfs. > > the number of files that exceeded 144B name limit was only 3 in 40000 > files. > > I will be happy if cwfs64x natively accepts longer name, but the > requirement > > is almost endless. for example, OSX support 1024B names. > > I wonder if making NAMELEN larger is the only way to handle the problem. > > without a different structure, it is the only way to handle the problem. > > a few things to keep in mind about file names. file names when they > appear in 9p messages can't be split between messages. this applies > to walk, create, stat or read (of parent directory). i think this places > the restriction that maxnamelen <= IOUNIT - 43 bytes. the distribution > limits IOUNIT through the mnt driver to 8192+24. (9atom uses > 6*8k+24) > > there are two basic ways to change the format to deal with this > 1. provide an escape to point to auxillary storage. this is kind to > existing storage. > 2. make the name (and thus the directory entry) variable length. > > on our fs (which has python and some other nasties), the average > file length is 11. making the blocks variable length could save 25% > (62 directory entries per buffer). but it might be annoying to have > to migrate the whole fs. > > so since there are so few long names, why not waste a whole block > on them? if using the "standard" (ish) 8k raw block size (8180 for > data), the expansion of the header could be nil (through creative > encoding) and there would be 3 extra blocks taken for indirect names. > for your case, the cost for 144-byte file names would be that DIRPERBUF > goes from 47 to 31. so most directories > 31 entries will take > 1.5 x (in the big-O sense) their original space even if there are > no long names. > > - erik > > --089e0149cd4a645d6a04dfd96aba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
with 8K names, using base64, one could encode 6111 bytes o= f data in the name. i just did a quick inventory[*] of my $home; 74% of my = files have less than 6112 bytes of data.

[*]
% fn pctfileslessthan6k () {
x=3D`{du -na $home|wc -l}
y=3D`{du -na $home|awk '$1 < 6112 = {print $0}'|wc -l}
pct=3D`{echo '= 2k ' $y $x ' / 100 * p' | dc}
echo $pct
}
% pctfileslessthan6k
74.00
%=A0
<= div class=3D"gmail_extra">

On Sun, Jun 23= , 2013 at 7:08 AM, erik quanstrom <quanstro@quanstro.net> wrote:
On Sun Jun 23 09:38:01 EDT= 2013, arisawa@ar.aichi-u.ac.jp= wrote:
> Thank you cinap,
>
> I tried to copy all my =A0Dropbox data to cwfs.
> the number of files that exceeded 144B name limit was only 3 in 40000 = files.
> I will be happy if cwfs64x natively accepts longer name, but the requi= rement
> is almost endless. for example, OSX support 1024B names.
> I wonder if making NAMELEN larger is the only way =A0to handle the pro= blem.

without a different structure, it is the only way to handle the probl= em.

a few things to keep in mind about file names. =A0file names when they
appear in 9p messages can't be split between messages. =A0this applies<= br> to walk, create, stat or read (of parent directory). =A0i think this places=
the restriction that maxnamelen <=3D IOUNIT - 43 bytes. =A0the distribut= ion
limits IOUNIT through the mnt driver to 8192+24. =A0(9atom uses
6*8k+24)

there are two basic ways to change the format to deal with this
1. =A0provide an escape to point to auxillary storage. =A0this is kind to existing storage.
2. =A0make the name (and thus the directory entry) variable length.

on our fs (which has python and some other nasties), the average
file length is 11. =A0making the blocks variable length could save 25%
(62 directory entries per buffer). =A0but it might be annoying to have
to migrate the whole fs.

so since there are so few long names, why not waste a whole block
on them? =A0if using the "standard" (ish) 8k raw block size (8180= for
data), the expansion of the header could be nil (through creative
encoding) and there would be 3 extra blocks taken for indirect names.
for your case, the cost for 144-byte file names would be that DIRPERBUF
goes from 47 to 31. =A0so most directories > 31 entries will take
1.5 x (in the big-O sense) their original space even if there are
no long names.

- erik


--089e0149cd4a645d6a04dfd96aba--