Re: extending the maximum filename length

On Fri, Sep 8, 2017 at 10:15 AM, Julian Elischer <julian_at_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