Blobcache gc

[rohanphadnis-thunder]

Overview

This PR implements the GET /api/v2/blobs?domain_id=X&blob_id=Y API call in nydusd.

The goal of this PR is to access the ref counters, allowing for safe garbage collection in the blobcache.

Related Issues

No related issues but this method was marked as a todo!().

Change Details

We define BlobCacheInfoEntry and BlobCacheInfoList structs. We implement a method handler and expose it to the nyduysd api.

Test Results

N/A

Change Type

• Add Unit Tests
• Feature Addition
• Documentation Update
• Code Refactoring
• Performance Improvement
• Other (please describe)

Self-Checklist

• I have run a code style check and addressed any warnings/errors.
• I have added appropriate comments to my code (if applicable).
• I have updated the documentation (if applicable).
• I have written appropriate unit tests.

[codecov]

Codecov Report

❌ Patch coverage is 88.88889% with 15 lines in your changes missing coverage. Please review.
✅ Project coverage is 58.34%. Comparing base (821a512) to head (374d66d).

Files with missing lines	Patch %	Lines
src/bin/nydusd/api_server_glue.rs	0.00%	15 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1894      +/-   ##
==========================================
+ Coverage   58.28%   58.34%   +0.06%     
==========================================
  Files         200      200              
  Lines       52946    53080     +134     
  Branches    45749    45883     +134     
==========================================
+ Hits        30859    30969     +110     
- Misses      20635    20657      +22     
- Partials     1452     1454       +2     

Files with missing lines	Coverage Δ
api/src/http.rs	0.00% <ø> (ø)
service/src/blob_cache.rs	86.52% <100.00%> (+3.03%)	⬆️
src/bin/nydusd/api_server_glue.rs	0.00% <0.00%> (ø)

... and 6 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[imeoer]

Hi @rohanphadnis-thunder, can we directly use the underlying_files field from GET /api/v1/daemon? The blob reference counting should be handled by the upper-level manager, such as the nydus-snapshotter, which can call APIs of all managed nydusds to calculate the blob reference counts.

[BraveY]

Hi, Thanks for the PR.
The ref_count exposed by this API is inaccurate for non-singleton modes.
Currently, BlobCacheMgr is shared across all bootstraps only in singleton mode (fscache). In this mode, the ref_count correctly reflects how many bootstraps reference a data blob within that single nydusd process.
However, in fusedev/virtiofs mode, each container/image gets its own nydusd process, and each process has its own isolated BlobCacheMgr. The API returns ref_count from DAEMON_CONTROLLER.get_blob_cache_mgr(), which only sees bootstraps managed by that specific daemon process.
This means:

• Singleton mode: ref_count = all references within this nydusd ✓
• Fusedev mode: ref_count = only references from this container's bootstrap ✗
  For accurate GC at the system level, the upper layer (e.g., nydus-snapshotter) would need to aggregate ref_counts across all nydusd instances, which this API doesn't support.

So. I agree with Imeoer. Using the underlying_files field from GET /api/v1/daemon is a good idea.