Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Jun 2011 11:45:06 -0700 (PDT)
From:      Todd Wasson <tsw5@duke.edu>
To:        freebsd-stable@freebsd.org
Subject:   zfs on geli vs. geli on zfs (via zvol)
Message-ID:  <alpine.BSF.2.00.1106281131250.23640@skylab.org>

next in thread | raw e-mail | index | archive | help
I've been thinking about how to best combine encryption and zfs on freebsd, and though I've seen some discussion about each individual option, I haven't found an explicit compare/contrast.  I'm thinking of either encryption the devices directly via geli and then making a zfs pool of the foo.eli devices once they're "geli attach"ed (zfs on geli) or making a zfs pool of the unencrypted devices and providing a zvol from the pool as a raw device which I can then use geli to encrypt, and lay a ufs (or even another zfs) filesystem down on this (geli on zfs).

While zfs on geli is less complex (in the sense that geli on zfs involves two layers of filesystems), I'm concerned as to whether encrypting the device will somehow affect zfs' ability to detect silent corruption, self-heal, or in any other way adversely affect zfs' functionality.  In my mind, if I use geli on zfs, then I've got zfs directly on a device and the zvol it's providing will be transparently gaining the benefits of zfs' various features, providing a "safety layer" against device failure and silent corruption that I'm not sure if geli would detect.

In a simpler sense, the question is this: if there is some damage to the device that zfs could putatively work around, if I were to have geli directly on that device, is it the case that geli would _not_ provide this protection and the device would be less robust than if it had had zfs directly on it?  If this is not the case, then it seems clear to me that the less complicated zfs on geli route is the way to go, but I'm curious if anyone has any input on this.

Thanks!


Todd



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1106281131250.23640>