Rainer Heilke wrote:
So, if I was an enterprise, I'd be willing to keep
enough empty LUNs
available to facilitate at least the migration of
one or more filesystems
if not complete pools.
You might be, but don't be surprised when the Financials folks laugh you out of their
office. Large corporations do not make money by leaving wads of cash lying around, and
that's exactly what a few terabytes of unused storage in a high-end SAN is. This is in
addition to the laughter generated by the comment that, "not a big deal if the
Financials and HR databases are offline for three days while we do the migration."
Good luck writing up a business case that justifies this sort of fiscal generosity.
To be fair, you can replace vdevs with same-sized or larger vdevs online.
The issue is that you cannot replace with smaller vdevs nor can you
eliminate vdevs. In other words, I can migrate data around without
downtime, I just can't shrink or eliminate vdevs without send/recv.
This is where the philosophical disconnect lies. Everytime we descend
into this rathole, we stir up more confusion :-(
If you consider your pool of storage as a zpool, then the management of
subparts of the pool is done at the file system level. This concept is
different than other combinations of devices and file systems such as
SVM+UFS. When answering the ZFS shrink question, you need to make sure
you're not applying the old concepts to the new model.
Personally, I've never been in the situation where users ask for less storage,
but maybe I'm just the odd guy out? ;-) Others have offered cases where
a shrink or vdev restructuring could be useful. But I still see some
confusion with file system management (including zvols) and device management.
The shrink feature is primarily at the device management level.
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
