Bigger MAX_PATH (Was: Re: State of native encryption in ZFS)

[Willem Jan Withagen]

On 15-5-2016 12:45, Niall Douglas via freebsd-fs wrote:
> On 14 May 2016 at 16:09, K. Macy wrote:
> 
>>>> It’s not even clear how that encryption would be implemented or exposed.
>>>>  Per pool?  Per dataset?  Per folder?  Per file?  There have been
>>>> requests for all of the above at one time or another, and the key
>>>> management challenges for each are different.  They can also be
>>>> implemented at a layer above ZFS, given sufficient interest.
>>>
>>> If FreeBSD had a bigger PATH_MAX then stackable encryptions layers
>>> like ecryptfs (encfs?) would be viable choices. Because encrypted
>>> path components are so long, one runs very rapidly into the maximum
>>> path on the system when PATH_MAX is so low.
>>>
>>> I ended up actually installing ZFS on Linux with ecryptfs on top to
>>> solve this. Every 15 minutes it ZFS snapshot syncs with the FreeBSD
>>> edition. This works very well, apart from the poor performance of ZFS
>>> on Linux.
>>>
>>> ZFS handles long paths with ease. FreeBSD currently does not :(
>>
>> AFAICT that's a 1 line patch. Have you tried patching that and
>> rebuilding kernel, world, and any vulnerable ports?
> 
> The problem is apparently kernel structure bloat and that they want 
> to remove fixed maximum paths altogether so it would be boot 
> modifiable.
> 
> http://freebsd.1045724.n5.nabble.com/misc-184340-PATH-MAX-not-interope
> rable-with-Linux-td5864469.html
> 
> As laudable as the latter goal is, unfortunately OS X and Linux hard 
> code theirs, and much POSIX software will use whatever PATH_MAX is 
> set to. I'm therefore not sure the implementation cost is worth it.
> 
> In any case, a 1024 byte path limit is just 256 unicode characters 
> potentially. That's worse than Windows 95 :(

I'm pretty sure that just about everybody that runs a somewhat bigger
ZFS installation runs into this a one point or another.
The weekly locate database build nags (after every fresh install) me for
about 4 years already that it needs a larger path than 1024. And then I
just dig into the source to up the value. the locate.db does not really
care.

I think I go a reply from Jilles around that time, that changing the
defines might cause unwanted compatibility fallout.
That was an answer sure enough to keep my hands from just doing the
1-line patch.

Trying to port Ceph is also running into the limit in:
/usr/include/sys/syslimits.h:
#define NAME_MAX        255  /* max bytes in a file name */

but I also found:
/usr/include/stdio.h:
#define FILENAME_MAX    1024 /* must be <= PATH_MAX <sys/syslimits.h> */

So take a pick??

--WjW