Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That said, even if that function existed, expecting it to magically rebalance the whole pool to take into account the existing data is rather unrealistic

That is exactly what is required (well, you re-balance the vdev, not the pool) and is what is proposed and has been in the works for basically forever. SUN never prioritized this because it has few uses within the enterprise (but extremely valuable for home users).

Your example is quite misleading. Here's is a much more common and realistic scenario.

6x2TB RaidZ2 = 8 usable, 4 lost to parity.

Now, imagine that you want to expand the pool with 4 TB. Being able to add to a raidz vdev would result in this:

8x2TB RaidZ2 = 12 Usable, 4 lost to parity. (ridiculously cheap, no further waste at all)

Current scenario:

6x2TB RaidZ2 + 4x2TB RaidZ2 = 12 Usable, 8 lost to parity. (expensive, lower performance, more power, more noise, requires more harddrive slots (this is often a very important aspect for home-setups))

The waste is outrageous. And the consequences from this waste reflects every aspect of designing a home-setup (as to avoid the above scenario) with ZFS and is vastly different to how you would design a system with, for instance, raid6 with expansion in mind.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: