> On Mar 3, 2016, at 1:53 AM, Steven Hartland <[email protected]> wrote: > > On 03/03/2016 03:41, PK1048 wrote: >>> 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. >> > This mirrors my own thoughts on the situation, for a silly example zpool > destroy <pool> will action without any prompting, yes you can recover from > that but you get the idea. > > It shouldn't be about preventing people shooting themselves in the foot, its > about making sure they know know the risks when you give them the gun.
Agree. FWIW, in our commercial product (InterModal Data) it is not possible for a storage admin to make this mistake. We have sophisticated logic to ensure all pools construction meets business requirements. This is just one case, but the problem space is quite large. -- richard ------------------------------------------- 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
