Hi,
I need to be a little bit more precise in how I formulate comments:
1. Yes, zpool remove is a desirable feature, no doubt about that.
2. Most of the cases where customers ask for "zpool remove" can be solved
with zfs send/receive or with zpool replace. Think Pareto's 80-20 rule.
2a. The cost of doing 2., including extra scratch storage space or scheduling
related work into planned downtimes is smaller than the cost of not using
ZFS at all.
2b. Even in the remaining 20% of cases (figuratively speaking, YMMV) where
zpool remove would be the only solution, I feel that the cost of
sacrificing the extra storage space that would have become available
through "zpool remove" is smaller than the cost of the project not
benefitting from the rest of ZFS' features.
3. Bottom line: Everybody wants zpool remove as early as possible, but IMHO
this is not an objective barrier to entry for ZFS.
Note my use of the word "objective". I do feel that we have to implement
zpool remove for subjective reasons, but that is a non technical matter.
Is this an agreeable summary of the situation?
Best regards,
Constantin
--
Constantin Gonzalez Sun Microsystems GmbH, Germany
Platform Technology Group, Client Solutions http://www.sun.de/
Tel.: +49 89/4 60 08-25 91 http://blogs.sun.com/constantin/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
