Martin wrote:
You are the 2nd customer I've ever heard of to use shrink.
This attitude seems to be a common theme in ZFS discussions: "No enterprise uses
shrink, only grow."
Maybe. The enterprise I work for requires that every change be reversible and
repeatable. Every change requires a backout plan and that plan better be fast
and nondisruptive.
Who are these enterprise admins who can honestly state that they have no requirement to
reverse operations? Who runs a 24x7 storage system and will look you in the eye and
state, "The storage decisions (parity count, number of devices in a stripe, etc.)
that I make today will be valid until the end of time and will NEVER need nondisruptive
adjustment. Every storage decision I made in 1993 when we first installed RAID is still
correct and has needed no changes despite changes in our business models."
My experience is that this attitude about enterprise storage borders on insane.
What's wrong with make a new pool.. safely copy the data. verify data
and then delete the old pool.. Who in the enterprise just allocates a
massive pool and then one day wants to shrink it... For home nas I
could see this being useful.. I'm not aruging there isn't a use case,
but in terms of where my vote for time/energy of the developers goes..
I'd have to concur there's more useful things out there. OTOH...
once/if the block reallocation code is dropped (webrev?) the shrinking
of a pool should be a lot easier. I don't mean to go off on a side
rant, but afaik this code is written and should have been available. If
we all pressured Green-bytes with an open letter it would maybe
help...... The legal issues around this are what's holding it all up.
@Sun people can't comment I'm sure, but this is what I speculate.
./C
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
