Bug #10005


Cannot Fix pool misconfiguration because other top level device is raidz.

Added by Till Wegmüller over 5 years ago. Updated over 4 years ago.

Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:
External Bug:



I had a slight mishap. Instead of typing
zpool add bkpool spare c18t0d0

I typed
zpool add bkpool c18t0d0

without the spare. So basicly added the device as top level vdev to the pool.
And it turns out I now cannot remove that device:
zpool remove bkpool c18t0d0
cannot remove c18t0d0: invalid config; all top-level vdevs must have the same sector size and not be raidz.

That is a problem on my part and I probybly am screwed now as this is a productive pool. And I have absolutely no chance of migrating to another pool anytime soon.

However I am of the opinion that the removal should be allowed to work given that the disk Is only single and not raidz itself and there is no section in zpool-features(5) mentioning that problem.

Related issues

Related to illumos gate - Bug #10012: vioblk should not accept an all-zero serial numberClosedJoshua M. Clulow2018-11-28

Related to illumos gate - Feature #11329: improved Virtio frameworkClosedJoshua M. Clulow

Actions #1

Updated by Till Wegmüller over 5 years ago

After reading into the Original implementation blog post from delphix. Could it be that a Resilver blocks the device removal? If so the error message should be changed.

Actions #2

Updated by Till Wegmüller about 5 years ago

Turns out there was either a regression or a missing Patch back on OI 2018.04 that allowed me to add the device without requiring -f

Server Osnet-incorporation is 2018.0.0-17625

In my Local Machines OI 2018.10 I needed to use -f to be able to test the situation. osnet-incorporation 2018.0.0-17649

Actions #3

Updated by Till Wegmüller over 4 years ago

After some testing with the Machine I found the Problem.

Pre-flight Checks in ZFS react differently than ZFS when it is writing to disk. Basically the Pre-flight checks deduplicates disk that have the same serial. This happens with VIRTIOBLK unless you have the serial option set on the Qemu Command line. So this problem is caused by that behavior and me not having the serial option set before. I now have fixed that with new disks.

This Bug can thus be closed as it is handled by #10012 , #11329 and others that refurbish the virtio framework/drivers

Actions #4

Updated by Till Wegmüller over 4 years ago

  • Related to Bug #10012: vioblk should not accept an all-zero serial number added
Actions #5

Updated by Till Wegmüller over 4 years ago

Actions #6

Updated by Dan McDonald over 4 years ago

  • Status changed from New to Closed

Per the above, this bug is being closed.


Also available in: Atom PDF