Re: Geli and ZFS
On Oct 9, 2013, at 6:43 AM, yudi v yudi@gmail.com wrote: Generally, it's recommended to let ZFS manage the whole disk if possible, so I was wondering if the second option is better. I will be using couple of 3TB HDDs mirrored for data and want to encrypt them. IIRC, there is/was a major performance-difference on Solaris between using ZFS on a partition, or a whole disk. FreeBSD is happy with either. The two alternatives you mentioned were: ZFS over GELI over disk and ZFS over GELI over ZFS over disk While ZFS wouldn't get the raw disk in setup #1, the left-most ZFS wouldn't get it in the second scenario either. I am hoping someone with an in-depth understanding of ZFS will be able to offer some insight. What I usually do and recommend is using GPT with labels for the partitions you'll put GELI/ZFS on. There's a couple of different reasons for this: * It'll let you create your zpool on /dev/gpt/label, which will make it easy to find even when the device moves (harddisk-renumbering, changes from internal ATA to USB enclosure… ) * You don't run things through ZFS twice. * The disk is fully encrypted. * etc Terje signature.asc Description: Message signed with OpenPGP using GPGMail
Geli and ZFS
* * -- There are few different ways to set-up geli with ZFS. I just want to get some opinions (benefits and disadvantages) about the below two options *First option*: (most commonly encountered set-up) Have geli on the block device and ZFS on top of the geli provider. * Second option:* Create a ZFS Volume on a block device, then create geli provider on top of the ZFS volume, and finally, ZFS datasets on top. Generally, it's recommended to let ZFS manage the whole disk if possible, so I was wondering if the second option is better. I will be using couple of 3TB HDDs mirrored for data and want to encrypt them. I am hoping someone with an in-depth understanding of ZFS will be able to offer some insight. -- Kind regards, Yudi ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
zfs over geli over zfs (was: Re: zfs flag denoting unclean shutdown?)
On 10/02/2013 08:13 PM, Matthew Seaman wrote: On 02/10/2013 16:34, Nikos Vassiliadis wrote: Is there a way to know if a zfs pool had an unclean shutdown? An attribute or maybe something during mount time similar to what ufs does (WARNING: / was not properly dismounted)? Other than looking at the system logs for evidence of an abnormal shutdown, no. (Absence of anything in the logs is pretty good evidence for the system falling over pretty hard... Usually something to do with the power being turned off.) However, due to the design of ZFS unclean shutdowns like this are nowhere near as problematic as on UFS. Basically, you're guaranteed that what is written on disk is always consistent. You might lose a few transactions -- essentially the last few seconds of file system activity -- but that doesn't usually make a great deal of difference after the system reboots again. Oh, yeah -- absolutely no time will be needed to be spent cleaning and repairing filesystems: with ZFS, reboot after crash is as fast as a normal reboot. Thanks Matthew, I realized I should have used a more appropriate subject. I'll explain what my actual goal is:) I am after a really specific use-case and the last minute transactions are important. Using a zpool over geli over a zvol. I'd like to know if during shutdown the kernel flushes all zfs files caches in order so these last minutes transactions won't be lost. The unmounting order is far from obvious (zfs over geli over zfs) and i wonder if such a scheme will succeed. I can't afford losing the last transactions of my home dir every time i shutdown my laptop;) The obvious solution is to create two slices and dedicate a slice to geli. Like this: mypool lives on slice1 myencpool lives on slice2.eli I am after this: mypool lives on slice1 myencpool lives on /dev/zvol/mypool/avolume.eli The second scheme will allow me to have an encypted home and not to pre-allocate space. A quick test showed that it might work... On the other hand conceptually seems like a very bad idea haha. I think I've heard people doing this zfs over geli over zfs before... Thanks for any thoughts, Nikos ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: zfs over geli over zfs
On 03/10/2013 17:20, Nikos Vassiliadis wrote: I am after a really specific use-case and the last minute transactions are important. Using a zpool over geli over a zvol. I'd like to know if during shutdown the kernel flushes all zfs files caches in order so these last minutes transactions won't be lost. The unmounting order is far from obvious (zfs over geli over zfs) and i wonder if such a scheme will succeed. I can't afford losing the last transactions of my home dir every time i shutdown my laptop;) If it's a normal clean shutdown, then yes, all pending transactions will be committed to persistent storage. Normally you'ld do something like this by creating geli devices on disk partitions (usually via gpt nowadays), and then creating your zpool from those geli devices. (Typically you'ld just use one geli device in your zvol, which doesn't offer any resilience but avoids potential cryptographical fubars like having two crypttexts known to come from the same plaintext: something that can make it considerably easier to break the encryption. Using a zfs exported as a raw device layered with geli is a good way to get round that, but I think you're probably better off creating a standard UFS on top of the geli partition, rather than creating a second layer of zpool and zfses. (I don't actually know: this is just me guessing without ever having tried this in practice. I'll willingly cede to anyone with actual experience of this sort of thing.) Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
