perf: Optimize dirInode prevDirListingTimeStamp by using atomic.Int64 instead of time.Time

[vedantdas-source]

Description

This PR optimizes the dirInode struct by converting the prevDirListingTimeStamp field from a time.Time struct into an atomic.Int64 representing Unix nanoseconds. This reduces memory overhead per cached directory and eliminates a latent thread-safety data race during concurrent kernel cache TTL checks.

• Latent Data Race Fix (Concurrency Safety) : Previously, ShouldInvalidateKernelListCache was performing concurrent, lock-free reads on the 24-byte time.Time struct. Because a 24-byte struct cannot be read in a single CPU instruction, this exposed the cache invalidation path to memory tearing (reading a partially-updated timestamp) during highly parallel FUSE directory lookups. By migrating to atomic.Int64.Load() and .Store(), we guarantee 100% thread-safe, lock-free reads at the hardware level without introducing any Mutex overhead.

• Memory Optimization : A time.Time struct consumes 24 bytes in Go. An atomic.Int64 consumes 8 bytes. Because GCSFuse heavily caches directories, shrinking this auxiliary field removes exactly 16 bytes from every dirInode in memory (reducing its size from 344B to 328B). This results in a ~1.6 MB heap RAM savings per 100,000 cached directories.

All existing directory and inode tests pass successfully.

Link to the issue in case of a bug fix.

Testing details

1. Manual - NA
2. Unit tests - Added a Test_ShouldInvalidateKernelListCache_RaceCondition to check for Race condition that is fixed by using atomic.Int64. To use the same test for the version of dirInode with time.Time change the d.prevDirListingTimeStamp.Store(d.cacheClock.Now().UnixNano()) to d.prevDirListingTimeStamp = d.cacheClock.Now()
3. Integration tests - NA

Any backward incompatible change? If so, please explain.

[gemini-code-assist]

Code Review

This pull request refactors the prevDirListingTimeStamp field in dirInode from time.Time to atomic.Int64 to ensure thread-safe operations, updating the associated cache invalidation logic and unit tests. The review feedback highlights critical issues where calling UnixNano() on an uninitialized or zero time.Time value will cause a panic in Go. Additionally, the feedback suggests handling potential clock skew defensively to prevent the cache from serving stale data indefinitely.

[codecov]

Codecov Report

❌ Patch coverage is 85.71429% with 2 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (radix-trie-cache@e6ee233). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
internal/fs/inode/dir.go	85.71%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@                 Coverage Diff                 @@
##             radix-trie-cache    #4862   +/-   ##
===================================================
  Coverage                    ?   83.73%           
===================================================
  Files                       ?      171           
  Lines                       ?    21117           
  Branches                    ?        0           
===================================================
  Hits                        ?    17683           
  Misses                      ?     2770           
  Partials                    ?      664           

Flag	Coverage Δ
unittests	83.73% <85.71%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.