> - We need to avoid customers thinking "Veritas can shrink, ZFS can't". That > is wrong. ZFS _filesystems_ grow and shrink all the time, it's just the > pools below them that can just grow. And Veritas does not even have pools.
I'm sure that this issue is different for different environments, but I assure you it wasn't raised because we're looking at a spec chart and someone saw a missing check in the ZFS column. The ability to deallocate in-use storage without having to migrate the existing data is used today by many administrators. We'll live with this not being possible in ZFS at the moment, but the limitation is real and the flexibility of filesystems within the pool doesn't alleviate it. > Sorry if I'm stating the obvious or stuff that has been discussed before, > but the more I think about zpool remove, the more I think it's a question > of willingness to plan/work/script/provision vs. a real show stopper. Show stopper would depend on the environment. It's certainly not that in many places. I agree that if I could exactly plan all my storage perfectly in advance, then several ways that it would be really useful would be reduced. However one of the reasons to have it is precisely because it is so difficult to get good predictions for storage use. I know just a touch of the internals of ZFS to understand why remove/split/evacuate is much more difficult than it might be in simpler volume managers. I'm happy we've got what we have today and that people have already thought up ways of attacking this problem to make ZFS even better. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
