State of native encryption in ZFS
Niall Douglas
s_sourceforge at nedprod.com
Sat May 14 20:20:21 UTC 2016
On 14 May 2016 at 11:03, Jordan Hubbard 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 :(
Niall
--
ned Productions Limited Consulting
http://www.nedproductions.biz/
http://ie.linkedin.com/in/nialldouglas/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SMime.p7s
Type: application/x-pkcs7-signature
Size: 6360 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20160514/40042f20/attachment.bin>
More information about the freebsd-fs
mailing list