`zpool create' fails on geli ...

[Fabian Keil]

Zeus Panchenko <zeus at ibs.dn.ua> wrote:

> I am trying to get ZFS on GELI disk ...

Good idea, I never use ZFS without it.
 
> Here is the issue:
> 
> #> uname -a
> FreeBSD 9.0-RELEASE #0 amd64
> 
> for /dev/ada2 I do:
> 
> #> 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:
> 
>         # geli restore /var/backups/ada2.eli /dev/ada2
> 
> 
> #> geli attach -k /path/key /dev/ada2
> 
> now I have .eli device
> 
> #> 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
> 
> now I am trying to create zfs on it:
> 
> >  zpool create geliz /dev/ada2.eli
> cannot create 'geliz': one or more devices is currently unavailable
> 
> `zpool create -f ...' gave the same result and in messages I have plenty
> rows like these:
> 
> 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 
> #> dd if=/dev/random of=/dev/ada2.eli bs=10m count=10
> 10+0 records in
> 10+0 records out
> 104857600 bytes transferred in 7.124000 secs (14718922 bytes/sec)
> 
> 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
> 
> pool was successfully created 
> 
> but pool status looks weird for me:
> 
> #> 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 unaffected.
> 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:
> 
>         NAME        STATE     READ WRITE CKSUM
>         geliz       ONLINE       0     0     0
>           ada2.eli  ONLINE      10     0     0
> 
> errors: No known data errors
> 
> after `zscub' and `zpool clear' I have clean pool:
> 
> #> 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:
> 
> 	NAME        STATE     READ WRITE CKSUM
> 	geliz       ONLINE       0     0     0
> 	  ada2.eli  ONLINE       0     0     0
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20120821/b41bb82a/signature.pgp