@g6094199 Cheers, that has helped.
I’ve managed to reproduce what I believe to be the same state here, ie same disk icons, same redirect role state. To do so required changing a prior managed pool with a btrfs in partition member, via the command line, into a whole disk pool. In short the upshot of this is that the redirect role is maintained (currently intended behaviour but in an unintended and unrecognised system state): ie I couldn’t get to this state from within the UI. Anyway we are in a catch 22 there as there are safeguards against changing the redirect role, even if orphaned apparently. This is all well and good but not in your case.
Long and short is I think I now understand this situation Rockstor wise and have exact notes on how to reproduce it, but given that it only occurs after extensive cli manipulation of the pool, and that the changes to adapt to this scenario are all on fairly sensitive and otherwise well behaved code I think a adaptation is not going to arrive soon. But as and when we introduce whole disk roles, which is what I think your disk icon tool-tips will indicate (mouse over the tab icon on the disk page) "Whole Disk Role found, click to inspect / edit.” we can reference this behaviour then. But currently there are no whole disk roles, that message is the UI’s logic of “I have a redirect role but no partitions, must be a whole disk role.”
No export required with btrfs. As long as it is cleanly unmounted it just needs to be mounted again.
However your sentiment of a fresh import for the pool I agree with. That way all disk db entries are re-build from what they find, and to defaults. But only if the current persistent disk info is removed which can’t be done safely with the disks attached (well not easily anyway). So bar db edits to remove the now orphaned but intentionally persistent redirect roles, a more practical option is as per my previous instructions in a previous thread with yourself:
Which brings us back to your already observed and reported import failure for pools with a prior use of “space_cache=v2”:
Let us know how you get on. It’s been a challenging but useful one this so thanks for working through it. I was originally against the idea of supporting any kind of partitioned device but it was requested multiple times and in the long run I think it will be good as then we can have import / export to non native devices, attached locally, that are almost always partitioned. So pros (flexibility) and cons (complexity).
Hope that helps.