special vdev must match topology

jenksdrummer

Patron
Joined
Jun 7, 2011
Messages
250
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

actually does care
Administrator
Moderator
iXsystems
Joined
Feb 6, 2014
Messages
5,110
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

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

Yorick

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