Martin wrote:
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.
Maybe, but maybe not see below...
2. Make a new pool
3. Quiesce the pool and cause a TOTAL outage during steps 4 through 9
That's not entirely true. You can use ZFS send/recv to do the major
first pass of #4 (and #5 against the snapshot) Live before the total
outage.
Then after you quiesce everything, you could use an incremental
send/recv copy the changes since then quickly, reducing down time.
I'd probably run a second full verify anyway, but in theory, I beleive
the ZFS checksums are used in the send/recv process to ensure that there
isn't any corruption, so after enough positive experience, I might start
to skip the second verify.
This should greatly reduce the length of the down time.
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.
In an Enterprise, a change for performance should have been tested on
another identical non-production system before being implemented on the
production one.
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.
All that said, as a personal home user, this is a feature I'm hoping for
all the time. :)
-Kyle
Thanks again,
Marty
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
