Cleanup opportunities

Light-touch maintenance ideas surfaced from a scan of the master branch (commit 7aac2a2c5b7c882e68c1ce017d8256be2feea27f). Given the repository's "no longer maintained" status, these are observations rather than action items.

Largest production source files

These are the candidates most likely to benefit from being split:

File	Bytes (≈)	What it covers
cmd/site-replication.go	189,199	Cluster-to-cluster sync orchestration.
cmd/metrics-v2.go	136,834	Every v2 Prometheus metric inlined.
cmd/object-handlers.go	123,497	Most S3 verb handlers.
cmd/bucket-replication.go	121,043	Per-bucket replication worker pool.
cmd/admin-handlers.go	102,056	Trace, profile, info, inspect, listen, prefix-import, ...
cmd/api-errors.go	95,264	The S3 error catalogue.
cmd/xl-storage.go	93,937	The on-disk drive driver.
cmd/admin-handlers-users.go	92,766	IAM admin endpoints.
cmd/erasure-server-pool.go	91,306	Top-level ObjectLayer.
cmd/iam-store.go	89,181	IAM persistence + cache.

The metrics-v2 file in particular could be split per concern the way v3 already is. Site replication is hard to split without breaking the orchestration, but new replicated entity types should ideally land in their own file.

TODO/FIXME/HACK comments

A grep across cmd/ and internal/ Go sources finds ~83 TODO/FIXME/HACK comments — small for a 200K-line codebase. They cluster around:

• Healing edge cases (cmd/erasure-healing.go, cmd/global-heal.go).
• Replication backlog handling (cmd/bucket-replication.go).
• Object Lock retention math (cmd/bucket-object-lock.go).
• A few // TODO: remove after v2 is settled markers around legacy format paths (cmd/xl-storage-format-v2-legacy.go).

Generated code volume

*_gen.go files produced by tinylib/msgp add up to several MB of Go. They are committed (CI rejects diffs without them). When trimming dependencies, adding new msgp types means new generated code — keep an eye on the size.

Dependency surface

go.mod lists ~80 direct + many indirect dependencies. Some ride along through specific notification targets (Kafka, NATS, AMQP, ES, MQTT, MySQL/Postgres/Redis/NSQ). For deployments that don't use those targets, the unused code is still in the binary. A future refactor could put each target behind a build tag.

Old code paths still in the repo

• cmd/signature-v2.go — only needed for very old clients.
• cmd/xl-storage-format-v1.go — only encountered on legacy upgrades.
• cmd/xl-storage-format-v2-legacy.go — keeps the v1 → v2 migration alive.

These are unlikely to be removed soon: every existing v1 cluster needs them to upgrade. They will probably outlive the maintained window of the community repo.

Inactive helpers

Some files surface as "tagging-along":

• cmd/dummy-handlers.go — placeholders for some S3 features that return canned responses.
• cmd/crossdomain-xml-handler.go — Flash-era cross-domain XML, kept for backwards compatibility.
• internal/init/ — small init hooks; unlikely to grow.

None of these are bugs; they're just unlikely to need new contributions.

Potential consolidation

• The two metrics endpoints (v2 + v3) have a lot of double-bookkeeping. A future change could make v2 a thin wrapper over v3 collectors.
• The storage REST and grid layers serve overlapping use cases. Long-term, the grid path is faster; consolidating would simplify ops.

Suggested follow-ups

If someone is going to invest in cleanup, the highest-leverage paths are:

1. Split cmd/metrics-v2.go per concern, similar to the v3 layout.
2. Move per-target notification SDKs behind build tags so binaries can be slimmer.
3. Tighten the test-to-code ratio in cmd/site-replication.go — it has fewer unit tests per KB than peers.
4. Document the threading model for cmd/global-heal.go and cmd/data-scanner.go; those interactions are subtle and live in code comments today.