`zpool create' fails on geli ...
Locked
 
|
|
Zeus Panchenko <[hidden email]> 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: 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. > ... | 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 checksums for the whole provider as described in the man page. Fabian |
signature.asc (203 bytes)
|
|
|
|
|
|
Zeus Panchenko <[hidden email]> wrote:
> resume: > > if geli was initialized with `-a' than we need to fill whole of it to > initialize checksums what will make it possible to `zpool create ...' > > something like this: > > geli init -K /path/key -s 4096 -a hmac/sha256 -e aes-xts /dev/adaX > geli attach -k /path/key /dev/adaX > dd if=/dev/zero of=/dev/adaX.eli bs=10m > zpool create geliz /dev/adaX.eli > > but it's better to > > geli init -K /path/key -s 4096 -e aes-xts /dev/adaX to me that "-s 4096" makes sense when using ZFS. I'm not claiming that it's obviously wrong, but I'm not aware of any benchmarks that show that it's better than the default in any way. Fabian |
Loading...
| Powered by Nabble | Edit this page |