fs: expose frsize field in statfs

[verycosy]

Expose f_frsize from libuv's uv_statfs_t as statfs.frsize.

libuv 1.52.0 added f_frsize to uv_statfs_t, and this dependency update has already landed in Node.js (5bebd7e),
so users can now compute accurate disk usage on every filesystem type.

Per POSIX, f_blocks, f_bfree, and f_bavail are in units of f_frsize, not f_bsize. On most filesystems the two values happen to be equal, so blocks * bsize gives a correct result. However, some filesystem drivers report a larger bsize as the I/O transfer size while frsize remains at the actual block size, producing a significant overestimation.

I hit this on a Docker container using virtiofs with a bind-mounted host directory:

$ node -e "console.log(fs.statfsSync('/data'))"
StatFs {
  bsize: 1048576,   // 1 MiB — I/O transfer size
  frsize: 4096,     // 4 KiB — actual block size
  blocks: 120699413,
  ...
}

Calculation	Result
blocks × frsize	~460 GB	correct
blocks × bsize	~117,870 GB	256× overestimation

Without frsize exposed, there is no way to work around this using the Node.js API alone.

See also libuv/libuv#4983 where the same problem was discussed.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/71807/

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.71%. Comparing base (bf452bb) to head (c3a761a).
⚠️ Report is 12 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #62277      +/-   ##
==========================================
- Coverage   89.71%   89.71%   -0.01%     
==========================================
  Files         694      694              
  Lines      214216   214218       +2     
  Branches    41114    41115       +1     
==========================================
+ Hits       192176   192177       +1     
+ Misses      14106    14105       -1     
- Partials     7934     7936       +2     

Files with missing lines	Coverage Δ
lib/internal/fs/utils.js	99.68% <100.00%> (+<0.01%)	⬆️
src/node_file-inl.h	87.71% <100.00%> (+0.05%)	⬆️
src/node_file.h	78.43% <ø> (ø)

... and 27 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.

[verycosy]

Hi, All "with shared libraries" CI jobs fail with:

src/node_file-inl.h:156:25: error: no member named 'f_frsize' in 'uv_statfs_s'

These jobs build with --shared-libuv against Nix's libuv 1.51.0, which doesn't have f_frsize (added in 1.52.0). nixpkgs master is still at 1.51.0 as well.

Should we wait for the nixpkgs libuv update?

[verycosy]

Hi, just a quick update on this.

The shared libraries CI issue should now be resolved:

• nixpkgs-unstable (832efc09b...) now includes libuv 1.52.0
• The nixpkgs pin update has been merged (tools: update nixpkgs-unstable to 832efc09b4caf6b4569fbf9dc01bec3082a #62486)
• There was a libuv revert, but it's unrelated to f_frsize (deps: libuv: revert 3a9a6e3e6b #62511)

I've rebased on main. The shared libraries CI should pass now.

[verycosy]

The remaining CI failure test-http2-close-while-writing appears to be a flaky test unrelated to this PR.
Could someone re-trigger the CI?

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/72347/

[gurgunday]

lgtm