> I think the request is to remove vdev's from a pool. > Not currently possible. Is this in the works?
Actually, I think this is two requests, hashed over hundreds of times in this forum: 1. Remove a vdev from a pool 2. Nondisruptively change vdev geometry #1 above has a stunningly obvious use case. Suppose, despite your best efforts, QA, planning and walkthroughs, you accidentally fat finger a "zpool attach" and unintentionally "zpool add" a disk to a pool. There is no way to reverse that operation without *significant* downtime. I have discussed #2 above multiple times and has at least one obvious use case. Suppose, just for a minute, that over the years since you deployed a zfs pool with nearly constant uptime, that your business needs change and you need to add a disk to a RAIDZ vdev, or move from RAIDZ1 to RAIDZ2, or disks have grown so big that you wish to remove a disk from a vdev. The responses from the community on the two requests seem to be: 1. Don't ever make this mistake and if you do, then tough luck 2. No business ever changes, or technology never changes, or zfs deployments have short lives, or businesses are perfectly ok with large downtimes to effect geometry changes. Both responses seem antithetical to the zfs ethos of survivability in the face of errors and nondisruptive flexibility. Honestly, I still don't understand the resistance to adding those features. -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
