>>>>> "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.
Description: PGP signature
_______________________________________________ zfs-discuss mailing list firstname.lastname@example.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss