Hello. > 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.
This depends on where you define "most". In the cases I am looking at, I would have to disagree. > 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. Not really. In a SAN environment, many of the ZFS features you list are either already in place, or irrelevant. As I commented to Al Hopper, if your company has a SAN, they're going to expect you to use it effectively. If your data is critical (and the last five years have seen a successful argument that SAN storage should be used for this data), then you aren't going to be able to convince management to use cheaper storage with ZFS any time soon. One other thing we've found is that "cheap storage", and by that I'm including an older SAN frame we have, doesn't have the cache and speed to keep up with the database usage on the ZPool. Performance sucks, and the developers and testers are getting uptight. Luckily our data shuffle should be done by Friday, and they'll all be back on the high-end SAN. So, combine these with the cost of high-end SAN storage, and you have a strong case for giving back unused space (and largely negating your 2b argument). Without the ability to give back one LUN of a 5-LUN zpool, ZFS buys us two things: 1) it's faster (that includes admin, as well as performance) 2) I can create a storage pool with 2 million+ files/inodes. The other features, while I see them as vital to other people's environments, aren't that big to ours, largely due to our SAN. The export/import will be good during lifecycle upgrades, though (ok, make that three things ;-). I hope that helps clarify my arguments, as your statements clarified yours. > Best regards, > Constantin Cheers, Rainer This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
