Shawn Ferry wrote:
On Mar 3, 2008, at 2:14 PM, Jonathan Loran wrote:
Now I know this is counterculture, but it's biting me in the back side
right now, and ruining my life.
I have a storage array (iSCSI SAN) that is performing badly, and
requires some upgrades/reconfiguration. I have a second storage array
that I wanted to set up as a ZFS mirror so I could free the bad array
for upgrades. The live array is only 15% utilized. It is 3.82TB in
size. The second array that I setup up is just short of that at
3.7TB.
Obviously I can't set this up as a mirror, since it's too small. But
given the low utilization, why the heck not? The way ZFS works, there
is no reason why you can't shrink a pool with a smaller mirror in the
same way you could grow it by detaching a mirror to larger storage?
It
may require an export/import or the like, but why not?
You can't shrink a pool.
Not now at least. Probably not ever.
What I'm left with now is to do more expensive modifications to the
new
mirror to increase its size, or using zfs send | receive or rsync to
copy the data, and have an extended down time for our users. Yuck!
Why do you need extended downtime to use zfs send|recv? I would think
that the only outage you would need to take would be on cutover to the
new
array.
The following may help:
http://blogs.sun.com/constantin/entry/useful_zfs_snapshot_replicator_script
That is very useful, thanks! Most of my work done for me. And I
thought I would have to write this myself.
From a tunning perspective however, I'm still thinking about canning
the whole iSCSI idea for this particular box and setting up a separate
standalone NFS/ZFS server. I can still use this script to get data across.
Jon
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
