Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 8 Aug 2014 11:30:18 -0400
From:      Paul Kraus <paul@kraus-haus.org>
To:        Scott Bennett <bennett@sdf.org>, FreeBSD Questions !!!! <freebsd-questions@freebsd.org>
Subject:   Re: some ZFS questions
Message-ID:  <27DAA821-0303-4D51-ADA7-7780DB8FE85D@kraus-haus.org>
In-Reply-To: <201408070816.s778G9ug015988@sdf.org>
References:  <201408070816.s778G9ug015988@sdf.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 7, 2014, at 4:16, Scott Bennett <bennett@sdf.org> wrote:

>     One thing I ran across was the following from the zpool(8) man =
page.
>=20
>  "For pools to be portable, you must give the zpool command whole
>  disks, not just slices, so that ZFS can label the disks with portable
>  EFI labels. Otherwise, disk drivers on platforms of different endian-
>  ness will not recognize the disks.=94

Here is where understanding *why* helps you make better decisions. In =
order for a zpool to be importable (is that even a word?) on a given =
system, the underlying OS must be able to read the parse the partition =
information. Since the *only* partition system that *all* the OSes that =
support ZFS understand is EFI, you need to use that if you want to have =
a truly portable zpool. I *think* you can manually create the EFI and =
just put zpools in the various partitions, but I am not positive.

If you only care about moving zpools between FreeBSD systems, and KNOW =
that you will NEVER want to import this pool on, for example, a Solaris =
system, then you can use any partition system FreeBSD understands. I =
have used GPT and moved zpools around between FreeBSD systems without a =
problem.

The critical part is that the OS must understand the partitioning and be =
able to present to the ZFS kernel module the data from within the =
partitions. Each partition that contains a zpool top level vdev will =
include 4 copies of the ZFS header, 2 at the start of the device and 2 =
at the end (note that I am saying device here, that could be an entire =
disk or a partition or even a file acting as a block device). So, if the =
ZFS code can read all 4 labels from the device, it can import this vdev, =
if it can import a sufficient number of vdevs that make up a zpool, it =
can import the zpool.

> If I have one raidzN comprising .eli partitions and another raidzN =
comprising
> a set of unencrypted partitions on those same drives, will I be able =
to
> export both raidzN pools from a 9-STABLE system and then import them
> into, say, a 10-STABLE system on a different Intel amd64 machine?

I am not familiar with FreeBSD .eli partitions, I assume at some layer =
below the block device the OS is encrypting the data here. If that is a =
valid assumption, then I=92ll take a stab at answering :-) If the OS can =
read the data from the device and find the ZFS labels it can import that =
vdev (and with enough vdevs it can import the zpool).

>  By your
> answer to question 1), it would seem that I need to have two raidzN =
pools,
> although there might be a number of benefits to having both encrypted =
and
> unencrypted file systems allocated inside a single pool were that an =
option.

Oracle has done work on ZFS to permit native encryption within ZFS. I do =
not know off the top of my head if that is on a zpool or dataset basis. =
I expect that it is probably on a dataset basis, so you could have both =
encrypted and unencrypted datasets within one zpool (just as we can have =
both compressed and uncompressed datasets).

--
Paul Kraus
paul@kraus-haus.org




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?27DAA821-0303-4D51-ADA7-7780DB8FE85D>