On Mon, Feb 08, 2010 at 11:28:11PM +0100, Lasse Osterild wrote:
Ok thanks I know that the amount of used space will vary, but what's
the usefulness of the total size when ie in my pool above 4 x 1G
(roughly, depending on recordsize) are reserved for parity, it's not
like it's useable for anything else :) I just don't see the point
when it's a raidz or raidz2 pool, but I guess I am missing something
here.
The basis of raidz is that each block is its own raid stripe, with its
own layout. At present, this only matters for the size of the stripe.
For example, if I write a single 512-byte block, to a dual-parity
raidz2, I will write three blocks, to three disks. With a larger
block, I will have more data over more disks, until the block is big
enough to stripe evenly over all of them. As the block gets bigger
yet, more is written to each disk as part of the stripe, and the
parity units get bigger to match the size of the largest data unit.
This "rounding" can very often mean that different disks have
different amounts of data for each stripe.
Crucially, it also means the ratio of parity-to-data is not fixed.
This tends to average out on a pool with lots of data and mixed
block sizes, but not always; consider an extreme case of a pool
containing only datasets with blocksize=512. That's what the comments
in the documentation are referring to, and the major reason for the
zpool output you see.
In future, it may go further and be more important.
Just as the data count per stripe can vary, there's nothing
fundamental in the raidz layout that says that the same parity count
and method has to be used for the entire pool, either. Raidz already
degrades to simple mirroring in some of the same small-stripe cases
discussed above.
There's no particular reason, in theory, why they could not also have
different amounts of parity on a per-block basis. I imagine that when
bp-rewrite and the ability to reshape pools comes along, this will
indeed be the case, at least during transition. As a simple example,
when reshaping a raidz1 to a raidz2 by adding a disk, there will be
blocks with single parity and other blocks with dual for a time until
the operation is finished.
Maybe one day in the future, there will just be a basic "raidz" vdev
type, and we can set dataset properties for the number of additional
parity blocks each should get. This might be a little like we can
currently set "copies", including that it would only affect new writes
and lead to very mixed redundancy states.
Noone has actually said this is a real goal, and the reasons it's not
presently allowed include administrative and operational simplicity as
well as implementation and testing constraints, but I think it would
be handy and cool.
--
Dan.
