Register for the iXsystems Community to get an ad-free experience and exclusive discounts in our eBay Store.

special vdev must match topology

jenksdrummer

Member
Joined
Jun 7, 2011
Messages
92
Earlier when I built my pool I didn't think anything of it and created it with 6 mirrored vdevs; a mirrored metadata vdev, a single cache, and a mirrored log vdev. World was happy, etc.

As I got to rebuild that pool due to a dataset removal causing a panic/reboot, I thought I'd see what performance is like with a pair of Z2 vdevs this time around, and the rest being of the same allocations; and I got the warning about the vdev topology not being right. I can force it, it seems, but thought I'd pose the question "why" they need to match; to what reason would there be to have a requirement Z2 metadata vdev? (else risk being an unsupported configuration) - I understand the need for redundancy as the pool surviving a failure would be dependent on that redundancy (unlike cache vdev; as that's a read cache, not a write cache)

Anyway, thanks!

1588787711607.png
 

HoneyBadger

Mushroom! Mushroom!
Joined
Feb 6, 2014
Messages
2,453
In this case, I'm guessing it's because your main vdevs can tolerate two failures (RAIDZ2) but you're setting up metadata/special vdevs with single failure tolerance.

If this is a purely lab environment and you're free to screw around, what happens if you try to set up a mirror3 for the metadata? That might go through as "will tolerate 2 failures" - or in a similar vein, if your data vdevs are RAIDZ1, will it give the same alert on mirrors for metadata?
 

jenksdrummer

Member
Joined
Jun 7, 2011
Messages
92
Understandable the difference, just curious why it matters outside of redundancy being established?
 

Yorick

Neophyte Sage
Joined
Nov 4, 2018
Messages
1,231
My understanding is that special allocation vdevs have to be mirrors. This may be a middleware quirk.
 
Top