Date: Mon, 16 May 2016 15:18:17 +0200 From: Willem Jan Withagen <wjw@digiware.nl> To: Niall Douglas <s_sourceforge@nedprod.com>, "freebsd-fs@FreeBSD.org" <freebsd-fs@freebsd.org> Subject: Bigger MAX_PATH (Was: Re: State of native encryption in ZFS) Message-ID: <9ead4b28-9711-5e38-483f-ef9eaf0bc583@digiware.nl> In-Reply-To: <57385356.4525.E728971@s_sourceforge.nedprod.com> References: <5736E7B4.1000409@gmail.com> <57378707.19425.B54772B@s_sourceforge.nedprod.com> <CAHM0Q_PGvBRbUFOhmin4RKaDKRTRJyjieuaZ5_tjPerK4eRz=w@mail.gmail.com> <57385356.4525.E728971@s_sourceforge.nedprod.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9ead4b28-9711-5e38-483f-ef9eaf0bc583>