From owner-freebsd-fs@freebsd.org Mon May 16 13:18:30 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B05EB3D28C for ; Mon, 16 May 2016 13:18:30 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1FE4818B9 for ; Mon, 16 May 2016 13:18:29 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id B393815340D; Mon, 16 May 2016 15:18:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cjn8AI7kTrdo; Mon, 16 May 2016 15:18:17 +0200 (CEST) Received: from [192.168.10.10] (asus [192.168.10.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 6EA0A153401; Mon, 16 May 2016 15:18:17 +0200 (CEST) Subject: Bigger MAX_PATH (Was: Re: State of native encryption in ZFS) To: Niall Douglas , "freebsd-fs@FreeBSD.org" References: <5736E7B4.1000409@gmail.com> <57378707.19425.B54772B@s_sourceforge.nedprod.com> <57385356.4525.E728971@s_sourceforge.nedprod.com> From: Willem Jan Withagen Message-ID: <9ead4b28-9711-5e38-483f-ef9eaf0bc583@digiware.nl> Date: Mon, 16 May 2016 15:18:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <57385356.4525.E728971@s_sourceforge.nedprod.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 13:18:30 -0000 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 */ So take a pick?? --WjW