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

2011/7/1 Todd Wasson <tsw5@duke.edu>:
> Thanks to both C. P. and Pete for your responses. =A0Comments 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 o=
f problems back to zfs that Pete referred to? =A0Maybe 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... =A0This, 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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"