Date: Wed, 06 Aug 2014 02:32:47 -0500 From: Scott Bennett <bennett@sdf.org> To: freebsd-questions@freebsd.org Subject: some ZFS questions Message-ID: <201408060732.s767WlPP027322@sdf.org>
next in thread | raw e-mail | index | archive | help
I have a number of questions that I need answered before I go about
setting up any raidz pools. They are in no particular order.
1) What is the recommended method of using geli encryption with
ZFS? Does one first create .eli devices and then specify those
.eli devices in the zpool(8) command as the devices to include
in the pool? Or is there some way to create the pool first and
then encrypt the pool? Or maybe "zfs create -V size volname"
and then "geli init /dev/zvol/volname" and
"newfs /dev/zvol/volname.eli"?
2) How does one start or stop a pool? From what I've read, it
appears that ZFS automatically starts all the pools at once. If
there is a problem after a crash that causes ZFS to decide to
run some sort of repairs without waiting for a go-ahead from a
human, ZFS might create still more problems. For example, if
a set of identically partitioned drives has a pool made of one
partition from each drive and another pool made from a different
set of partitions, a rebuild after a failed/corrupted drive might
start on both pools at once, thereby hammering all of the drives
mercilessly until something else, hardware or software, failed.
Having a way to allow one to complete before starting another
would be critical in such a configuration. Also, one might need
stop a pool in order to switch hardware connections around. I
see the zpool(8) command has a "reopen" command, but I don't see
a "close" counterpart, nor a description of when a "reopen" might
be used.
3) If a raidz2 or raidz3 loses more than one component, does one
simply replace and rebuild all of them at once? Or is it necessary
to rebuild them serially? In some particular order?
4) At present, I'm running 9-STABLE i386. The box has 4 GB of
memory, but the kernel ignores a bit over 1 GB of it. The ZFS
documentation recommends building a kernel with
"options KVA_PAGES=512" for use with ZFS. What impact would that
have on the rest of my system? Would the default, which is in my
currently running kernel as modified from GENERIC, suffice for low-
intensity use until I can upgrade to amd64? (Low-intensity here
means copying the data from other file systems into the pools,
followed by occasional reading or writing. I am currently the only
human user. The machine is mostly used for number crunching and as
a tor relay.)
5) When I upgrade to amd64, the usage would continue to be low-
intensity as defined above. Will the 4 GB be enough? I will not
be using the "deduplication" feature at all.
6) I have a much fancier computer sitting unused that I intend to
put into service fairly soon after getting my current disk and data
situation resolved. The drives that would be in use for raidz
pools I would like to attach to that system when it is ready. It
also has 4 GB of memory, but would start out as an amd64 system and
might well have another 2 GB or 4 GB added at some point(s), though
not immediately. What problems/pitfalls/precautions would I need
to have in mind and be prepared for in order to move those drives
from the current system to that newer one?
Depending upon the answers to the above, I may well have further
questions, but those are the most worrisome to me at the moment. Any
information/suggestions would be most welcome. Thanks much in advance for
any you can offer.
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201408060732.s767WlPP027322>