Jacob Yocom-Piatt wrote:
have a freebsd 7.0-beta4 machine attached to an external disk
enclosure and would like feedback on the following setup: have RAID-Z
on 4 disks, ZFS volume that takes up entire RAID-Z, use ZVOL from
volume for encryption via geli, use .eli (decrypted) device to make
another ZFS pool. the idea being "no time/resources wasted doing fscks
plus encryption sans hardware RAID".
Unless I'm misunderstanding your objective, geli'ing the disks and
creating a pool ontop of the encrypted disks (zpool create secure raidz
da0.eli da1.eli da2.eli da3.eli) would also work, and would be far
easier to maintain. Your data would still be encrypted and you would
still need to provide the passphrase to make the pool accessible.
translated to commands this reads:
# zpool create p_a raidz /dev/mfid1 /dev/mfid2 /dev/mfid3 /dev/mfid4
# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
p_a 2.72T 4.02G 2.71T 0% ONLINE -
# zfs create -V 2048g p_a/vol
# geli init -K /root/p_a.key -s 4096 -l 256 /dev/zvol/p_a/vol
# geli attach -k /root/p_a.key /dev/zvol/p_a/vol
# zpool create a /dev/zvol/p_a/vol.eli
i got a reboot while scp-ing some files to /a (only got ~3 GB in) from
another machine with the above setup. am currently waiting far too
long for a rm -R <directory> to complete under /a. will test if any of
this behavior is repeatable.
i welcome opinions or suggestions on the stability of such a setup
(ZFS-geli-ZFS) and if this is not stable, as the reboot i just
experienced would indicate, suggestions on alternative configurations
that allow use of geli and minimize or eliminate fsck time. i do have
a preference for no hardware RAID since it ties us to a particular
card. will furnish a proper bug report if the reboots are repeatable
in the aforementioned scenario.
NOTE: please CC me since i am not yet subscribed to this list
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"