> On Mar 2, 2016, at 22:14, ilove zfs <[email protected]> wrote: > > Yes, exactly. The unintended consequence of saving one group from a > fat-fingered "zpool add" will be dooming another group to pool loss.
There are plenty of ways to set yourself up for pool loss. One of the strengths of Unix and Unix-like OSes is the ability to do things that may not be best practice, with the understanding that you _are_ taking a risk. That flexibility in my mind more than outweighs the risk. I have, on very rare occasions, had to migrate a configuration through a state where there was little to no redundancy. It was the only way for me to get from point A to point B with the hardware available. I understood the risks involved and decided the benefits of point B were worth the, in my opinion, very minimal risk. I also managed a large pool of storage that fell into the “too big to fail” category… it would have taken 3 weeks to restore from a backup and the lawyers, court cases, and judges would not accept “we lost our storage system, can you wait three weeks for that document”. We took no risks with that storage configuration. Educate and warn me about the risks, but let me make the decision. Please do not limit a potentially very useful feature because some users may mis-use it. I would like to see this feature upstreamed even without mirror/raidz support, but with very clear documentation and with the ability to remove a simple vdev from a pool even if other vdevs are mirror/raidz. > Your proposed workaround, "to allow the detached device to be substituted for > the failed device," mostly addresses the concern except for the fact that it > is only viable if the detached device is still available when the failure > occurs. Keeping the detached device available and untouched until the removal > completes could be encouraged by the documentation, I guess, but we can't > expect everyone will see that advice, let alone heed it. > > "Please don't integrate" is perhaps a little strong. A bad "zpool add" can > also lead to pool loss if the added device fails during the process of > rebuilding the pool from scratch to recover from the bad add. I just don't > think the removal feature sans mirror support should be viewed as "half a > loaf is better than no loaf" as if it's all benefit with no costs. ------------------------------------------- openzfs-developer Archives: https://www.listbox.com/member/archive/274414/=now RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa Modify Your Subscription: https://www.listbox.com/member/?member_id=28015062&id_secret=28015062-f966d51c Powered by Listbox: http://www.listbox.com
