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