This issue originated from this discussion ThinkParQ/beegfs#70.

Storage target registration is a two step process where a storage nodes first registers all their targets then maps them to itself (ref: ThinkParQ/beegfs#70 (reply in thread)). If some targets are registered but then others fail, there may be targets in an "unmapped" state that don't have a node assigned yet. Currently most operations except beegfs pool list act like these targets don't exist. This is confusing because it result in inconsistent behavior and the targets cannot be cleaned up using beegfs target remove.

The proposed fix is to:

• Allow beegfs target commands to return and act on unmapped targets. We could consider adding an -a | --all flag to show these, but it might be better to just always show them (with the node column indicating a clear error like unmapped) so its more likely they are noticed.
• Update beegfs health check so the Checking Targets section has a new check ✅ Mapped -> All targets are mapped to a storage node.
  • We consider if there are other checks we want to add for entities in the mgmtd DB that might be in an unexpected state.