C, I appreciate the feedback and like you, do not wish to start a side rant, but rather understand this, because it is completely counter to my experience.
Allow me to respond based on my anecdotal experience. > What's wrong with make a new pool.. safely copy the data. verify data > and then delete the old pool.. You missed a few steps. The actual process would be more like the following. 1. Write up the steps and get approval from all affected parties -- In truth, the change would not make it past step 1. 2. Make a new pool 3. Quiesce the pool and cause a TOTAL outage during steps 4 through 9 4. Safely make a copy of the data 5. Verify the data 6. Export old pool 7. Import new pool 8. Restart server 9. Confirm all services are functioning correctly 10. Announce the outage has finished 11. Delete the old pool Note step 3 and let me know which 24x7 operation would tolerate an extended outage (because it would last for hours or days) on a critical production server. One solution is not to do this on a critical enterprise storage, and that's the point I am trying to make. > Who in the enterprise just allocates a > massive pool Everyone. > and then one day [months or years later] wants to shrink it... Business needs change. Technology changes. The project was a pilot and canceled. The extended pool didn't meet verification requirements, e,g, performance and the change must be backed out. Business growth estimates are grossly too high and the pool needs migration to a cheaper frame in order to keep costs in line with revenue. The pool was made of 40 of the largest disks at the time and now, 4 years later, only 10 disks are needed to accomplish the same thing while the 40 original disks are at EOL and no longer supported. The list goes on and on. > I'd have to concur there's more useful things out there. OTOH... That's probably true and I have not seen the priority list. I was merely amazed at the number of "Enterprises don't need this functionality" posts. Thanks again, Marty -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
