On 9/9/17 1:28 am, Conrad Meyer wrote:
On Fri, Sep 8, 2017 at 10:15 AM, Julian Elischer <jul...@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

(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.


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.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to