Date: Fri, 1 Jul 2011 11:46:26 +0300 From: nickolasbug@gmail.com To: Todd Wasson <tsw5@duke.edu> Cc: freebsd-stable@freebsd.org, "C. P. Ghost" <cpghost@cordula.ws>, Pete French <petefrench@ingresso.co.uk> Subject: Re: zfs on geli vs. geli on zfs (via zvol) Message-ID: <BANLkTimuVkm5RfpXDd_wghDwS5pQgijVkw@mail.gmail.com> In-Reply-To: <EFC7DAF3-D3C5-49CC-92B0-572D28E7A37C@duke.edu> References: <alpine.BSF.2.00.1106281131250.23640@skylab.org> <BANLkTi=Ck_yTxS70GX0-45-DOrVHLYq7gw@mail.gmail.com> <EFC7DAF3-D3C5-49CC-92B0-572D28E7A37C@duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTimuVkm5RfpXDd_wghDwS5pQgijVkw>