Date: Sun, 10 Sep 2017 00:09:33 +0800 From: Julian Elischer <julian@freebsd.org> To: cem@freebsd.org Cc: freebsd-current <freebsd-current@freebsd.org>, Rick Macklem <rmacklem@uoguelph.ca> Subject: Re: extending the maximum filename length Message-ID: <8d04540b-6daf-aa13-5648-0ec2541cbae6@freebsd.org> In-Reply-To: <CAG6CVpXxr%2B7j6dN0EUhQ95Rn9GQtakJOsAKCCyBoUJjfUU16Hw@mail.gmail.com> References: <0154558d-b2ad-af97-3960-3e392678f709@freebsd.org> <CAG6CVpXxr%2B7j6dN0EUhQ95Rn9GQtakJOsAKCCyBoUJjfUU16Hw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/9/17 1:28 am, Conrad Meyer wrote:
> On Fri, Sep 8, 2017 at 10:15 AM, Julian Elischer <julian@freebsd.org> wrote:
>> Has anyone using freeBSD ever increased NAME_MAX (filename maximum length)
>> and have any experience with it?
>>
>> We ($JOB) would recompile the entire system so intra-system compatibility
>> would probably be ok, and we have our own filesystem which would support it.
>>
>> But I wonder if anyone has tried it and hit unexpected problems.
>>
>>
>> reason: Chinese and Japanese people who have gotten into the habit of
>> having a filename of 256 CHINESE/JAPANESE characters in Microsoft and want
>> to store their files on a FreeBSD based server witout having to rename
>> everything. (3 bytes for each of those characters giving a limit of 83
>> characters).
>>
>> (though since each character is a word the names if I could read them must
>> be amazing)
>>
>>
>> NFS behaviour is one issue I don't know but would be interested in.. could
>> we SERVE such files?
> Hey Julian,
>
> We've done exactly this at Isilon.
>
> Basically we bumped NAME_MAX and related constants out by 4x (maximum
> length of a UTF-8 encoded Unicode character, in bytes). So NAME_MAX
> is 1023, PATH_MAX is 4096, and a bunch of follow-on equivalent/related
> constants are bumped similarly.
>
> To avoid breaking too many ABIs, we've retained a SHORT_NAME_MAX
> constant of 255 which several non-filesystem NAME_MAX users were
> converted to. Stuff like module name APIs, procstat, etc.
>
> Individual filesystems are free to implement and restrict maximum
> component lengths in VOP_LOOKUP. For us, we retained 255 bytes for
> basically all filesystems (see e.g. r316509, r313475) aside from IFS
> (the OneFS filesystem). For IFS we check that component names are 255
> ("MAXNAMCHARS") unicode codepoints or fewer (not all names shorter
> than NAME_MAX bytes are valid).
>
> NFS commonly does not support >255 byte names, so we have a hack there
> to export longer names as some shorter name plus a hash (total length
> of 255 bytes or fewer) to uniquely identify the file. SMB exports
> longer names just fine.
>
> Anyway, we'd love to shift some of these patches upstream, if there is
> interest in supporting this kind of thing.
>
> Sure, there are a few snags here and there and some ABIs change. But
> overall it seems to work pretty well.
>
> Best,
> Conrad
>
maybe we could get it into -current.
It'd be silly to have to have people re-inventing hte wheel all the time.
How about you put those changes into the reviews.freebsd.org and we
can get some general consensus on them.
We'll have to do similar for the Asian customers and anyone who uses
UTF-8. So it
would be silly to have to develop it all again (but subtly different
of course).
The key issue is how many system calls and other APIs would be broken,
and how many would be broken in a non backwards compatible way?
We would need it in a stable/10 and 11 branch but if the patch is isolated
enough we could carry it forward until we get to 12.
One has to allow people to do whatever they are used to with Windows.
And in this case the issue is serving files over samba to windows
machines.
Julian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8d04540b-6daf-aa13-5648-0ec2541cbae6>