Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Aug 2012 19:22:55 +0200
From:      Fabian Keil <freebsd-listen@fabiankeil.de>
To:        Zeus Panchenko <zeus@ibs.dn.ua>
Cc:        freebsd-fs@FreeBSD.ORG, freebsd-geom@FreeBSD.ORG
Subject:   Re: `zpool create' fails on geli ...
Message-ID:  <20120821192255.1048b445@fabiankeil.de>
In-Reply-To: <20120821190742.54449@relay.ibs.dn.ua>
References:  <20120821190742.54449@relay.ibs.dn.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/JtMKgxnF8HmUGIITc6GY6Fo
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Zeus Panchenko <zeus@ibs.dn.ua> 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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120821192255.1048b445>