Valery Fouques wrote:
The ability to shrink a pool by removing devices is the only reason my
enterprise is not yet using ZFS, simply because it prevents us from
easily migrating storage.
That logic is totally bogus AFAIC. There are so many advantages to
running ZFS that denying yourself that opportunity is very short sighted -
especially when there are lots of ways of working around this minor
feature deficiency.
I cannot let you say that.
Here in my company we are very interested in ZFS, but we do not care about the
RAID/mirror features, because we already have a SAN with RAID-5 disks, and dual
fabric connection to the hosts.
We would have migrated already if we could simply migrate data from a storage
array to another (which we do more often than you might think).
Currently we use (and pay for) VXVM, here is how we do a migration:
But you describe VxVM feature, not a file system feature.
1/ Allocate disks from the new array, visible by the host.
2/ Add the disks in the diskgroup.
3/ Run vxevac to evacuate data from "old" disks.
4/ Remove old disks from the DG.
If you explain how to do that with ZFS, no downtime, and new disks with
different capacities, you're my hero ;-)
zpool replace old-disk new-disk
The caveat is that new-disk must be as big or bigger than old-disk.
This caveat is the core of the shrink "problem"
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
