thanks for confirming my observation vis a vis the failure characteristics
of the pool. this is strictly experimentation as well; we thought there may
be no way to extend a raidz pool seamlessly, but wanted to test to see what
zpool did.
since the fundamental safety property of the pool is blown away by the
addition, it would be useful to generate a warning and maybe require
-f or something...
oz
David Dyer-Bennet wrote:
On 10/25/06, ozan s. yigit <[EMAIL PROTECTED]> wrote:
ah. looks like the new disk is not a part of the raidz set,
yet the diskspace in the pool increased appropriately.
Yes. A pool can hold many vdevs, an uses the space in all of them.
if this
pool is used as is, can it still offer the raidz guarantee?
No.
only for the bits that happen to fall into the raidz set but
not the additional disk?
Yes (and you can't control or determine where in the pool a file
landed, so you might as well regard that answer as "no" for all
practical purposes). Files will be spread across vdevs potentially.
i am confused about the overall failure characteristics of such
a setup. [maybe it is a boneheaded thing to do, but one gets no
warning from zpool if it is...]
I will stop short of calling it boneheaded, but...let's say I can't
think of a reason you'd want such a pool in production, other than
utter emergency shortage of diskpace coupled with shortage of places
to put new drives.
I got myself into this situation in my own early experimentation as
well. Non-production system, just playing around, so no harm done.
It's easy to do by mistake/confusion, and I do tend to agree that
zpool should issue a warning for that drastically differing a level of
redundancy on vdevs in a pool.
--
ozan s. yigit | [EMAIL PROTECTED] | http://nextbit.blogspot.com
you take a banana, you get a lunar landscape. -- j. van wijk
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
