Top level vdev removal seems to be incompletely implemented; no warning given it often can't bve executed.

Description

Note: I'm not sure this is a bug, but it's also not really a suggestion. It's more a request to maybe complete the development of a partially completed feature, or at least document it is incomplete in man pages and relevant docs.

zpool remove of top level vdevs is a significant new feature. But at the moment, it seems only partially implemented.

Requires entire pool (not just vdev being removed) to have mirrors only not raidz
Requires entire pool (not just vdev being removed) to have same sector sizes
Even when disks are all mirrors and have same sector sizes, may refuse to work. (Tested on a pool of mirrored 4096 logical/512 physical HDDs, sector sizes confirmed in console)

That's a problem if a user believes top level vdevs can be removed now, and finds they can't - but only discovers it at removal.

Since there's no other way to remove a top level vdev short of replicating the pool, this is a concern.

And also, what's with the demands on other vdevs? Nothing else in ZFS demands that vdevs have any specific sector or structure type, when copying data. Mostly, ZFS is transparent as to on-disk physical/logical sector sizes, or mirror vs raidz; it's just block sizes that count.

REQUEST:

Can we lose these 2 limitations, so that any top level vdev in any pool can be removed, not just some of them?

Problem/Justification

None

Impact

None

SmartDraw Connector

Katalon Manual Tests (BETA)

Activity

Show:

Alexander Motin 
August 31, 2020 at 3:05 PM

Those limitations are not artificial and not easy to remove due to the way how removal works (consequence of famous lack of real pointer rewrite in ZFS).  Those who want to understand the technical background can see the OpenZFS devsummit presentation: https://www.youtube.com/watch?v=KGnFhmG8gT0 .

I would generally discourage people from using device removal on data disks without good thinking, since the operation will never be fully completed, leaving some garbage in pool metadata.  It is better than nothing when needed, but should not be used routinely.

William Gryzbowski 
August 31, 2020 at 1:05 PM

Seems like this ticket should be filed in upstream OpenZFS github.

Stilez 
August 29, 2020 at 5:53 AM

Note: there is at least 1 other report of a user being stung by this issue, in the forums.

Third Party to Resolve

Details

Assignee

Reporter

Labels

Impact

Components

Fix versions

Affects versions

Priority

More fields

Katalon Platform

Created August 29, 2020 at 5:48 AM
Updated July 1, 2022 at 4:55 PM
Resolved August 31, 2020 at 3:05 PM