From owner-freebsd-fs@FreeBSD.ORG Tue Aug 21 17:30:06 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 529FD1065741; Tue, 21 Aug 2012 17:30:06 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.93]) by mx1.freebsd.org (Postfix) with ESMTP id E60928FC08; Tue, 21 Aug 2012 17:30:05 +0000 (UTC) Received: from [78.35.144.130] (helo=fabiankeil.de) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1T3sDJ-0006EO-PP; Tue, 21 Aug 2012 19:26:01 +0200 Date: Tue, 21 Aug 2012 19:22:55 +0200 From: Fabian Keil To: Zeus Panchenko Message-ID: <20120821192255.1048b445@fabiankeil.de> In-Reply-To: <20120821190742.54449@relay.ibs.dn.ua> References: <20120821190742.54449@relay.ibs.dn.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/JtMKgxnF8HmUGIITc6GY6Fo"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-fs@FreeBSD.ORG, freebsd-geom@FreeBSD.ORG Subject: Re: `zpool create' fails on geli ... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-fs@FreeBSD.ORG List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 17:30:06 -0000 --Sig_/JtMKgxnF8HmUGIITc6GY6Fo Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Zeus Panchenko wrote: > I am trying to get ZFS on GELI disk ... Good idea, I never use ZFS without it. =20 > Here is the issue: >=20 > #> uname -a > FreeBSD 9.0-RELEASE #0 amd64 >=20 > for /dev/ada2 I do: >=20 > #> geli init -K /path/key -s 4096 -a hmac/sha256 -e aes-xts /dev/ada2 > Enter new passphrase: > Reenter new passphrase: ZFS already provides checksums, so why do you want to use checksums for geli as well? In my opinion "-a hmac/sha256" doesn't add any protection in your case, while reducing the space that is available for ZFS and wasting cpu cycles. I'm not aware of any problem that can be detected by geli's integrity checks but wouldn't be detected by ZFS anyway. ZFS checksums actually offer better protection, as geli only checksums single sectors. > Metadata backup can be found in /var/backups/ada2.eli and > can be restored with the following command: >=20 > # geli restore /var/backups/ada2.eli /dev/ada2 >=20 >=20 > #> geli attach -k /path/key /dev/ada2 >=20 > now I have .eli device >=20 > #> ls -al /dev/*eli > lrwxr-xr-x 1 root wheel 8 Aug 16 15:43 /dev/ad14.eli -> ada2= .eli > crw-r----- 1 root operator 0, 99 Aug 16 15:43 /dev/ada2.eli >=20 > now I am trying to create zfs on it: >=20 > > zpool create geliz /dev/ada2.eli > cannot create 'geliz': one or more devices is currently unavailable >=20 > `zpool create -f ...' gave the same result and in messages I have plenty > rows like these: >=20 > cat /var/log/messages > ... > GEOM_ELI: ada2.eli: 131072 bytes corrupted at offset 444539600896. > GEOM_ELI: ada2.eli: 131072 bytes corrupted at offset 444539863040. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 270336. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 444539609088. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 444539871232. > GEOM_ELI: ada2.eli: 4096 bytes corrupted at offset 444540313600. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 65536. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 8192. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 0. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 262144. > ... Quoting geli(8): | DATA AUTHENTICATION | [..] | It is recommended to write to the whole provider before first use, in | order to make sure that all sectors and their corresponding checksums are | properly initialized into a consistent state. One can safely ignore data | authentication errors that occur immediately after the first time a | provider is attached and before it is initialized in this way. > but after=20 > #> dd if=3D/dev/random of=3D/dev/ada2.eli bs=3D10m count=3D10 > 10+0 records in > 10+0 records out > 104857600 bytes transferred in 7.124000 secs (14718922 bytes/sec) >=20 > I was able to do it! Because this forced geli to create the checksums for the first 100m. Using /dev/zero as source should have worked the same. > #> zpool create geliz /dev/ada2.eli >=20 > pool was successfully created=20 >=20 > but pool status looks weird for me: >=20 > #> zpool status geliz > pool: geliz > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are unaffect= ed. > action: Determine if the device needs to be replaced, and clear the errors > using 'zpool clear' or replace the device with 'zpool replace'. > see: http://www.sun.com/msg/ZFS-8000-9P > scan: none requested > config: >=20 > NAME STATE READ WRITE CKSUM > geliz ONLINE 0 0 0 > ada2.eli ONLINE 10 0 0 >=20 > errors: No known data errors >=20 > after `zscub' and `zpool clear' I have clean pool: >=20 > #> zpool status geliz > pool: geliz > state: ONLINE > scan: scrub repaired 0 in 0h0m with 0 errors on Thu Aug 16 16:36:44 2012 > config: >=20 > NAME STATE READ WRITE CKSUM > geliz ONLINE 0 0 0 > ada2.eli ONLINE 0 0 0 >=20 > errors: No known data errors I assume this is the result of not forcing geli to generate the checksums for the whole provider as described in the man page. Fabian --Sig_/JtMKgxnF8HmUGIITc6GY6Fo Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlAzw/IACgkQBYqIVf93VJ24bQCfWJgiathMk/WYuawZLqOlN8Uv eyEAn2fqN4oq4JcRUhLmq2aKh74ENc9w =TfIC -----END PGP SIGNATURE----- --Sig_/JtMKgxnF8HmUGIITc6GY6Fo--