From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: arisawa In-Reply-To: <0fd845b9ba300f41b4f0607ede960285@lyons.quanstro.net> Date: Mon, 24 Jun 2013 19:57:20 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96413B2B-5F5B-4C27-B2B5-483FB9B811D2@ar.aichi-u.ac.jp> <0fd845b9ba300f41b4f0607ede960285@lyons.quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] long filenames in cwfs Topicbox-Message-UUID: 67cf7950-ead8-11e9-9d60-3106f5b1d025 might be better idea than the one I have been considering. On 2013/06/23, at 23:08, erik quanstrom wrote: > On Sun Jun 23 09:38:01 EDT 2013, arisawa@ar.aichi-u.ac.jp wrote: >> Thank you cinap, >>=20 >> 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. >=20 > without a different structure, it is the only way to handle the = problem. >=20 > 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 <=3D IOUNIT - 43 bytes. the = distribution > limits IOUNIT through the mnt driver to 8192+24. (9atom uses > 6*8k+24) >=20 > 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. >=20 > 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. >=20 > 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=20 > 1.5 x (in the big-O sense) their original space even if there are > no long names. >=20 > - erik >=20