Is it possible to remove metadata VDEV from pool?

[martian9000]

Howdy folks, I have a pool comprised of three VDEVs:
Data VDEV: 3 x 4TB drives in 3 way mirror
Data VDEV: 3 x 10TB drives in 3 way mirror
Metadata VDEV: 2 x 110GB drives in 2 way mirror

I'm consolidating two systems in to one to save on electricity. I'm not 100% sure the new system will support bifurcation for the 2 110GB Optane drives which is why I'd like to explore removing them from the pool now in case I run in to issues during hardware rebuild. I've read similar posts indicating you can't remove a metadata VDEV if you're running any sort of RAIDZ. All of my VDEV are comprised of mirrors, however.

The TrueNAS SCALE GUI will let me click a button to remove the metadata mirror from the pool. My question is: what actually happens behind the scenes when I click to remove the metadata VDEV? Will TrueNAS copy all metadata back to the main data VDEVs or will it happily remove the metadata VDEV, thereby nuking the pool? Many thanks in advance.

 

[NugentS]

It depends,
Are we talking L2ARC (Metadata only) or L2ARC (full) or special vdev?

The first two are not pool critical and can just be removed - they are cache drives
The last should be removeable as you have mirrors - but will take a while as the vdev is evacuated to the main data vdevs.

 

[martian9000]

It depends,
Are we talking L2ARC (Metadata only) or L2ARC (full) or special vdev?

The first two are not pool critical and can just be removed - they are cache drives
The last should be removeable as you have mirrors - but will take a while as the vdev is evacuated to the main data vdevs.

It is a special vdev. I don't have any L2ARC configured. I appreciate the info, thank you! I'm still going to backup to BackBlaze just in case ;-)

 

[NugentS]

Its always worth doing a backup before doing something that might (for whatever reason) fubar the pool.

But you should be golden

 

[martian9000]

Closing the loop for any future weary internet travelers. Removing the Special metadata VDEV went off without a hitch. Click the buttons in the TrueNAS SCALE GUI, wait a few minutes and I was good to go. No more special VDEV and the pool is still healthy. Thank you again, NugentS.

 

[jenksdrummer]

Curious, and don't mean to hijack, but related...

Does this also work with special_small_blocks ?

 

[HoneyBadger]

Curious, and don't mean to hijack, but related...

Does this also work with special_small_blocks ?

Provided that your pool only contains mirror or stripe vdevs (and all top level vdevs have the same ashift value) then yes, removal will still work with or without special_small_blocks.

You can't selectively evacuate just the small-block or metadata from the special vdev though - only remove the entire vdev.

 

[Jorsher]

Thanks. Good to know that I can 'try' a special vdev and change my mind later if needed without needing to offload the pool to another.

 

[Ericloewe]

You do have a performance penalty after device removal, so it's not free, just a convenience.

 

[Etorix]

Thanks. Good to know that I can 'try' a special vdev and change my mind later if needed without needing to offload the pool to another.

Provided that your pool comprises only mirror vdevs!
Any raidz# vdev—which is the most likely configuration for data vdevs—makes that a one-way trip.

 

[Jorsher]

Provided that your pool comprises only mirror vdevs!
Any raidz# vdev—which is the most likely configuration for data vdevs—makes that a one-way trip.

Seems I misread 'can't' as 'can' in the first post. This is unfortunate, but less unfortunate than finding out the hard way :)

Thanks

 

[Etorix]

No misreading: OP had a "full mirrors" pool, and had read correct advice that one cannot remove a metadata vdev if the data pool is any form of raidz—which, again, is the most likely configuration for a large storage array which one would like to browse through at speed.

 

[Jorsher]

No misreading: OP had a "full mirrors" pool, and had read correct advice that one cannot remove a metadata vdev if the data pool is any form of raidz—which, again, is the most likely configuration for a large storage array which one would like to browse through at speed.

When I said that I misread, I meant that I misread. Meaning the OP was correct, and that I misread his post.

I hope that clears it up.