fix: Return empty GPFS performance metric rather than raising exception

[fregataa]

resolves #NNN (BA-MMM)

Summary

• Fixed unhandled GPFSNoMetricError exception in GPFS volume performance metric collection
• When GPFS performance metric data is unavailable, return an empty FSPerfMetric with zero values instead of raising an exception

Problem

The GPFSNoMetricError exception was raised when GPFS API returned no performance metric data (due to KeyError or IndexError), but this exception was not caught or handled anywhere in the codebase. This caused unexpected crashes when metrics were temporarily unavailable.

Solution

Instead of raising an unhandled exception, return a valid FSPerfMetric object with all values set to zero. This allows the system to gracefully handle cases where metric data is unavailable without disrupting normal operations.

Checklist: (if applicable)

• Milestone metadata specifying the target backport version
• Mention to the original issue
• Installer updates including:
  • Fixtures for db schema changes
  • New mandatory config options
• Update of end-to-end CLI integration tests in ai.backend.test
• API server-client counterparts (e.g., manager API -> client SDK)
• Test case(s) to:
  • Demonstrate the difference of before/after
  • Demonstrate the flow of abstract/conceptual models with a concrete implementation
• Documentation
  • Contents in the docs directory
  • docstrings in public interfaces and type annotations

[Copilot]

Pull request overview

This PR fixes a bug where GPFS performance metrics would cause an unhandled exception when unavailable. Instead of raising GPFSNoMetricError (which was not properly handled as an HTTP exception), the code now returns a zero-valued FSPerfMetric when metrics cannot be retrieved.

Changes:

• Return empty performance metrics (all zeros) instead of raising GPFSNoMetricError when GPFS metrics are unavailable
• Remove unused import of GPFSNoMetricError from the GPFS volume implementation

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Consider using -1 instead of 0 for unavailable metrics to be consistent with the VAST volume implementation. The VAST implementation uses -1 values to explicitly indicate that metrics are unavailable, which is more semantically correct than 0 (which could be confused with actual zero activity). This would make the error handling pattern more consistent across different storage backend implementations.

[jopemachine]

GPFSNoMetricError is not used anywhere, so we can remove it

[jopemachine]

Is there a reason for changing the behavior that previously raised an exception?
I think it would be helpful if the rationale were explained in the PR or the related issue.

[HyeockJinKim]

It looks like return an empty value instead of raising an error might be riskier.
What's the reason for this work?