>>>>> "j" == John <[EMAIL PROTECTED]> writes:
j> There is also the human error factor. If someone accidentally
j> grows a zpool
or worse, accidentally adds an unredundant vdev to a redundant pool.
Once you press return, all you can do is scramble to find mirrors for
it.
vdev removal is also neeeded to, for example, change each vdev in a
big pool of JBOD devices from mirroring to raidz2. in general, for
reconfiguring pools' layouts without outage, not just shrinking.
This online-layout-reconfig is also a Veritas selling point, yes?, or
is that Veritas feature considered too risky for actual use?
For my home user setup, the ability to grow a single vdev by replacing
all the disks within it with bigger ones, then export/import, is
probably good enough. Note however this is still not quite ``online''
because export/import is needed to claim the space. Though IIRC some
post here said that's fixed in the latest Nevadas, one would have to
look at the whole stack to make sure it's truly online---can FC and
iSCSI gracefully handle a target's changing size and report it to ZFS,
or does FC/iSCSI need to be whacked, or is size change only noticed at
zpool replace/attach time?
The thing that really made me wish for 'pvmove' / RFE 4852783 at home
so far is the recovering-from-mistaken-add scenario.
pgpQvOcQ6F2w3.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
