Is there a way in which ZFS can be prompted to redistribute a given filesystem over the all of the disks in its zpool?

I'm thinking of a scenario where I have a fixed size ZFS volume that's exported as a LUN over FC. The current zpool is small, just two 1TB mirrored disks, and the zvol is 750GB in total. If I were to suddenly expand the size of the zpool to, say, 12 1TB disks, I believe the zvol would still effectively be 'housed' on the first two spindles only.

Given that more spindles = more IOPS, what method could I use to 'redistribute' the zvol over all 12 spindles to take advantage of them?

link|improve this question

feedback

2 Answers

up vote 4 down vote accepted

You would need to rewrite your data to the expanded zpool in order to rebalance it. Otherwise, as time passes, your writes will be distributed across the entire pool.

link|improve this answer
I don't suppose there's a quick and easy way to do that... ? – growse Dec 16 '11 at 10:18
4  
zfs send | zfs recv – syneticon-dj Dec 16 '11 at 13:01
I'm going to go test that - can't believe something so simple would do it. :) – growse Dec 16 '11 at 17:31
Do report back, I've never done this and am curious too. – StrangeWill Jan 19 at 18:36
feedback

There is no reason for the zvol to be stored on the initial devices only. If you enlarge the pool, ZFS should span the new IOs on all of the available underlying devices. There is no fixed partitioning with ZFS. At least this is my understanding.

link|improve this answer
In my experience, this isn't true. While there's no 'fixed paritioning', ZFS won't move data around of its own free will outside of client IO requests. If you create the scenario I described, add more disks and then do some heavy IO on the original LUN, you'll only see activity on the first two disks in the array, because that's where the data is. ewwhite points out that over time it gets balanced, but I'm curious to know if there's a faster way of doing this. – growse Dec 16 '11 at 10:23
Sorry if I was unclear. Of course, the existing data won't move magically. Only updated data will be relocated evenly. That's what I meant with "new IOs". As far as existing static data is concerned, caching will also improve performance as long as blocks are read more than once. – jlliagre Dec 16 '11 at 16:47
feedback

Your Answer

 
or
required, but never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.