2011/7/1 Todd Wasson <t...@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 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
