zfs on geli vs. geli on zfs (via zvol)

[nickolasbug at gmail.com]

2011/7/1 Todd Wasson <tsw5 at duke.edu>:
> Thanks to both C. P. and Pete for your responses.  Comments inline:
>
>> Case 1.) is probably harmless, because geli would return a
>> corrupted sectors' content to zfs... which zfs will likely detect
>> because it wouldn't checksum correctly. So zfs will correct it
>> out of redundant storage, and write it back through a new
>> encryption. BE CAREFUL: don't enable hmac integrity checks
>> in geli, as that would prevent geli from returning corrupted
>> data and would result in hangs!
>
> Perhaps the hmac integrity checks were related to the lack of reporting of problems back to zfs that Pete referred to?  Maybe we need someone with more technical experience with the filesystem / disk access infrastructure to weigh in, but it still doesn't seem clear to me what the best option is.
>
>> Case 2.) is a bigger problem. If a sector containing vital
>> geli metadata (perhaps portions of keys?) gets corrupted,
>> and geli had no way to detect and/or correct this (e.g. by
>> using redundant sectors on the same .eli volume!), the whole
>> .eli, or maybe some stripes out of it, could become useless.
>> ZFS couldn't repair this at all... at least not automatically.
>> You'll have to MANUALLY reformat the failed .eli device, and
>> resilver it from zfs redundant storage later.
>
> This is precisely the kind of thing that made me think about putting zfs directly on the disks instead of geli...  This, and other unknown issues that could crop up and are out of geli's ability to guard against.
>

Agree. If you wanna have encrypted ZFS it's better to wait until zpool
version 30 (which supports encryption) will be ported to FreeBSD.


-------
wbr,
Nickolas