Re: zfs over geli over zfs

[Matthew Seaman]

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

zfs over geli over zfs (was: Re: zfs flag denoting unclean shutdown?)

[Nikos Vassiliadis]

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"