Date: Sat, 14 May 2016 16:09:36 -0700 From: "K. Macy" <kmacy@freebsd.org> To: Niall Douglas <s_sourceforge@nedprod.com> Cc: "freebsd-fs@FreeBSD.org" <freebsd-fs@freebsd.org> Subject: Re: State of native encryption in ZFS Message-ID: <CAHM0Q_PGvBRbUFOhmin4RKaDKRTRJyjieuaZ5_tjPerK4eRz=w@mail.gmail.com> In-Reply-To: <57378707.19425.B54772B@s_sourceforge.nedprod.com> References: <5736E7B4.1000409@gmail.com> <0CE6E456-CC25-4AED-A73E-F5BBE659F795@mail.turbofuzz.com> <57378707.19425.B54772B@s_sourceforge.nedprod.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 14, 2016 at 1:13 PM, Niall Douglas via freebsd-fs <freebsd-fs@freebsd.org> wrote: > On 14 May 2016 at 11:03, Jordan Hubbard wrote: > >> It=E2=80=99s 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? -M
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHM0Q_PGvBRbUFOhmin4RKaDKRTRJyjieuaZ5_tjPerK4eRz=w>