From owner-freebsd-stable@FreeBSD.ORG Fri Jul 1 08:46:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B99510656D3 for ; Fri, 1 Jul 2011 08:46:28 +0000 (UTC) (envelope-from nickolasbug@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id DAE768FC20 for ; Fri, 1 Jul 2011 08:46:27 +0000 (UTC) Received: by qwc9 with SMTP id 9so2060405qwc.13 for ; Fri, 01 Jul 2011 01:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vnf80JLzSPLlWg+1e7RJbgII9kp7Np2F2AII215JVZA=; b=bUcBDJmB0EAFR+WpLbwoKzNNu1mqkXJLjZfvSZP5YS4Bwo8r+bZJv9JniplR2YDAav JXRmzCUgF1b/NHd5fVNUrUOWn/Z8XQqwQll4HsH8QeAMflOoeJBGqzN5X+oLJm3VZa/H nu2Drok5sJvDsxlSAM2n5Ww/e2d686PXesMYE= MIME-Version: 1.0 Received: by 10.229.37.71 with SMTP id w7mr2390338qcd.15.1309509987029; Fri, 01 Jul 2011 01:46:27 -0700 (PDT) Received: by 10.229.102.17 with HTTP; Fri, 1 Jul 2011 01:46:26 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Jul 2011 11:46:26 +0300 Message-ID: From: nickolasbug@gmail.com To: Todd Wasson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, "C. P. Ghost" , Pete French Subject: Re: zfs on geli vs. geli on zfs (via zvol) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 08:46:28 -0000 2011/7/1 Todd Wasson : > 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