For anyone else looking for answers on this topic, I did a deep dive into the mc and minio source code to understand the mc admin heal command's behavior. Here is a summary of what I found, which I hope will be helpful.

Why Manual mc admin heal is Still Needed

MinIO has automatic healing mechanisms (on GET/PUT and a background scanner), but mc admin heal is a manual, immediate, and resource-intensive trigger for a full scan. It's particularly useful in specific scenarios where automatic healing might not be sufficient, such as healing objects that were written in a degraded state. The background scanner can also take a very long time (weeks or months) on large clusters, whereas mc admin heal provides an immediate way to verify and repair integrity.

How to Interpret the mc admin heal Output

The key is to understand that the output reflects the state after the healing attempt and that the different counters track different things.

1. The Progress Line: A/B objects (e.g., 255,374/8,857,285 objects)

• B (ObjectsScanned): This is straightforward – it's the total number of objects the command has scanned.
• A (ObjectsHealed): This counter is incremented only if the number of online shards for an object increases as a result of the heal operation. It counts the objects that were actually repaired.

2. The Summary Table (Green, Yellow, Red, Grey)

• Reflects the FINAL State: The colors in the summary table show the health of items after the heal operation is complete for that item.
• Counts Items, Not Just Objects: The table's total can be higher than the number of scanned objects because it also includes buckets.
• Color Definitions (for an EC:N+M setup, e.g., 8+4): The color is based on the number of available parity shards (i.e., surplusShards = online_shards - N).
  • Green: The object has high or full redundancy. For EC 8+4, this typically means 11 or 12 shards are online. It does not strictly mean 100% of shards are available.
  • Yellow: The object has reduced redundancy but is still perfectly readable and safe. For EC 8+4, this could mean 10 shards are online.
  • Red: The object is at critical risk. It has lost all parity and has just enough shards to be read (N shards online). For EC 8+4, this could be 8 or 9 shards. Any further loss will result in data loss.
  • Grey: The object is corrupted and unrecoverable. It has fewer than N shards online.

The Healing Algorithm in a Nutshell

1. Scan: mc iterates through objects, incrementing ObjectsScanned for each one.
2. Decide: The MinIO server checks if an object is missing any shards (.xl.meta or part.N). If even one shard is missing, it decides to heal.
3. Heal & Update ObjectsHealed: The server attempts to reconstruct the missing shards. If it succeeds in increasing the number of online shards, the mc client increments the ObjectsHealed counter.
4. Classify Final State: After the healing attempt, the mc client checks the object's final number of surplus shards and assigns it to a color category (Green, Yellow, Red) in the summary table. If the object is unrecoverable (<N shards), it's marked Grey.

I've compiled a more detailed analysis with code references from mc/cmd/admin-heal-ui.go and cmd/erasure-healing.go. The summary above captures the most critical points.

Hope this helps others!