Adding Second VDev, how to redistribute data?

[Reckman]

Is there any sort of command or shortcut to redestribute the Data evenly across the pool?

When switching my pool from RaidZ1 to RaidZ2, I ended up with all of my data on half of my disks in order to destroy and remake the pool. Now I assume 90% of my data is on the first vdev essentially cutting sustained read/writes in half?

I was going to slowly copy 1/2 of the data, delete the source, and repeat. That should even it out, but is rather cumbersome and time consuming.

 

[SirMaster]

They way you described it is really the only way to do it. I had to do it that way too, but it worked out well in the end.

 

[cyberjock]

It's also generally a waste of time. ZFS will preferentially decide what to stick where. And unless the "empty" vdev is bottlenecking your writes, it'll go to the second vdev where it should be.

tl/dr: don't worry about it. just add the vdev and don't mess with your pool. ZFS will make it all work in the long run.

 

[Reckman]

@cyberjock, I think that makes sense if the data is being cycled somewhat...mine is mostly static media / movies and such, so the items filling the first vdev won't ever be deleted under normal circumstances.

 

[cyberjock]

Exactly my point. Are you going to try to convince me that your media is going to be bottlenecked by your vdev? I'd be willing to bet the answer is "no", which means you're only going to be throwing data around because you can.

The bottom line, and if you search for the word 'redistribute' you'll find a bunch of threads on this, is that you aren't going to be able to tell the difference. The media that is being thrown down and read at high speeds will end up on 2 vdevs, while the slower stuff is fine however it is.


I'd be willing to bet you're running Gb LAN, which is certainly your bottleneck as I have no doubt that your vdev can easily do 3-4x the throughput of Gb LAN anyway.

So back to the original question.. you expect to see a performance gain in what again???

 

[cyberjock]

Don't get me wrong, I fully expect you to redistribute it and then come back and try to argue that it is so much faster now. More people do than don't, despite my advice. Then they provide some number that is *still* saturated at the LAN cable, so they wasted their time.

So either take my advice or don't. But just be warned I've watched people screw up CLI stuff and lose TB of data as a result.

So when you weigh potential mistakes that could be quite costly against a benefit you aren't going to be able to observe, why would you take that kind of risk? If that is your thing, please buy me $100 worth of lottery tickets and mail them to me. :)

This is risk and benefit management. For literally zero benefit you are incurring non-zero risk. You are also going to work your drives when you really don't need to. Nobody in their right mind would play with those odds.