Is it possible to revert a grown vdev?

[gregnostic]

Before I begin, let me say that I'm pretty sure I know the answer, but I figure it's worth asking just in case...

I'm in the unfortunate situation where the disks I've chosen for growing a vdev are having problems. The vdev (one of four) had six 3TB disks in RAID-Z2, and I replaced them with 10TB disks.

Given the way that the resilvering process works--by calculating parity based on the data that's actually been written, not based on all the addressable blocks on the disks--it seems to me like it might be theoretically possible to swap the smaller disks back in. Very little additional data has been written to the zpool since the vdev grew, so in terms of raw capacity the old disks would still be sufficient to contain the data currently on the new disks.

That said, everything I've ever read about ZFS indicates that once a vdev is grown, that's it. And that's what I expect the answer to be. I'm just kinda hoping to be proven wrong because it would make life a lot easier (and cheaper) right now if I could swap the old disks back in for the time being.

Does anyone know conclusively one way or the other?

 

[Arwen]

No, you can not shrink a vDev.

Whence the last disk finished it's re-silver, and ZFS has grown the vDev, it's too late.

 

[nightshade00013]

You can take the old disks and reinsert them and then create a new pool with them and then transfer the data back. But no way to shrink only grow.

 

[gregnostic]

Certainly seems to be the consensus that there's no situation in which reversion is possible. Thanks for the input!

 

[Ericloewe]

It's a mathematical/logical certainty more than a consensus, really.

 

[gregnostic]

It's a mathematical/logical certainty more than a consensus, really.

That rather depends on the code itself. It may very well be (and, in all likelihood, is) the case that the code doesn't allow it; but the actual implementation could also be less cut-and-dried than most users assume. As a programmer myself, I know that documentation doesn't always reflect the current state of the code and that users can assume one thing but the code does another.

Absent the input from someone who's familiar with the specific code path in question or someone who has specifically tried and failed to do this exact thing, all we can do is go by the user community's understanding of how it probably works.

 

[Ericloewe]

I'm telling you that it's not possible at all as of this writing. A limited, hacky form of vdev removal is being worked on. Generic, proper vdev removal is only possible with Block Pointer Rewrite.