Files
seaweedfs/test/fuse_integration
Chris Lu 7a7f220224 feat(mount): cap write buffer with -writeBufferSizeMB (#9066)
* feat(mount): cap write buffer with -writeBufferSizeMB

Without a bound on the per-mount write pipeline, sustained upload
failures (e.g. volume server returning "Volume Size Exceeded" while
the master hasn't yet rotated assignments) let sealed chunks pile up
across open file handles until the swap directory — by default
os.TempDir() — fills the disk. Reported on 4.19 filling /tmp to 1.8 TB
during a large rclone sync.

Add a global WriteBufferAccountant shared across every UploadPipeline
in a mount. Creating a new page chunk (memory or swap) first reserves
ChunkSize bytes; when the cap is reached the writer blocks until an
uploader finishes and releases, turning swap overflow into natural
FUSE-level backpressure instead of unbounded disk growth.

The new -writeBufferSizeMB flag (also accepted via fuse.conf) defaults
to 0 = unlimited, preserving current behavior. Reserve drops
chunksLock while blocking so uploader goroutines — which take
chunksLock on completion before calling Release — cannot deadlock,
and an oversized reservation on an empty accountant succeeds to avoid
single-handle starvation.

* fix(mount): plug write-budget leaks in pipeline Shutdown

Review on #9066 caught two accounting bugs on the Destroy() path:

1. Writable-chunk leak (high). SaveDataAt() reserves ChunkSize before
   inserting into writableChunks, but Shutdown() only iterated
   sealedChunks. Truncate / metadata-invalidation flows call Destroy()
   (via ResetDirtyPages) without flushing first, so any dirty but
   unsealed chunks would permanently shrink the global write budget.
   Shutdown now frees and releases writable chunks too.

2. Double release with racing uploader (medium). Shutdown called
   accountant.Release directly after FreeReference, while the async
   uploader goroutine did the same on normal completion — under a
   Destroy-before-flush race this could underflow the accountant and
   let later writes exceed the configured cap. Move accounting into
   SealedChunk.FreeReference itself: the refcount-zero transition is
   exactly-once by construction, so any number of FreeReference calls
   release the slot precisely once.

Add regression tests for the writable-leak and the FreeReference
idempotency guarantee.

* test(mount): remove sleep-based race in accountant blocking test

Address review nits on #9066:
- Replace time.Sleep(50ms) proxy for "goroutine entered Reserve" with
  a started channel the goroutine closes immediately before calling
  Reserve. Reserve cannot make progress until Release is called, so
  landed is guaranteed false after the handshake — no arbitrary wait.
- Short-circuit WriteBufferAccountant.Used() in unlimited mode for
  consistency with Reserve/Release, avoiding a mutex round-trip.

* test(mount): add end-to-end write-buffer cap integration test

Exercises the full write-budget plumbing with a small cap (4 chunks of
64 KiB = 256 KiB) shared across three UploadPipelines fed by six
concurrent writers. A gated saveFn models the "volume server rejecting
uploads" condition from the original report: no sealed chunk can drain
until the test opens the gate. A background sampler records the peak
value of accountant.Used() throughout the run.

The test asserts:
  - writers fill the budget and then block on Reserve (Used() stays at
    the cap while stalled)
  - Used() never exceeds the configured cap even under concurrent
    pressure from multiple pipelines
  - after the gate opens, writers drain to zero
  - peak observed Used() matches the cap (262144 bytes in this run)

While wiring this up, the race detector surfaced a pre-existing data
race on UploadPipeline.uploaderCount: the two glog.V(4) lines around
the atomic Add sites read the field non-atomically. Capture the new
value from AddInt32 and log that instead — one-liner each, no
behavioral change.

* test(fuse): end-to-end integration test for -writeBufferSizeMB

Exercise the new write-buffer cap against a real weed mount so CI
(fuse-integration.yml) covers the FUSE→upload-pipeline→filer path, not
just the in-package unit tests. Uses a 4 MiB cap with 2 MiB chunks so
every subtest's total write demand is multiples of the budget and
Reserve/Release must drive forward progress for writes to complete.

Subtests:
- ConcurrentLargeWrites: six parallel 6 MiB files (36 MiB total, ~18
  chunk allocations) through the same mount, verifies every byte
  round-trips.
- SingleFileExceedingCap: one 20 MiB file (10 chunks) through a single
  handle, catching any self-deadlock when the pipeline's own earlier
  chunks already fill the global budget.
- DoesNotDeadlockAfterPressure: final small write with a 30s timeout,
  catching budget-slot leaks that would otherwise hang subsequent
  writes on a still-full accountant.

Ran locally on Darwin with macfuse against a real weed mini + mount:
  === RUN   TestWriteBufferCap
  --- PASS: TestWriteBufferCap (1.82s)

* test(fuse): loosen write-buffer cap e2e test + fail-fast on hang

On Linux CI the previous configuration (-writeBufferSizeMB=4,
-concurrentWriters=4 against a 20 MiB single-handle write)
deterministically hung the "Run FUSE Integration Tests" step to the
45-minute workflow timeout, while on macOS / macfuse the same test
completes in ~2 seconds (see run 24386197483). The Linux hang shows
up after TestWriteBufferCap/ConcurrentLargeWrites completes cleanly,
then TestWriteBufferCap/SingleFileExceedingCap starts and never
emits its PASS line.

Change:
- Loosen the cap to 16 MiB (8 × 2 MiB chunk slots) and drop the
  custom -concurrentWriters override. The subtests still drive demand
  well above the cap (32 MiB concurrent, 12 MiB single-handle), so
  Reserve/Release is still on every chunk-allocation path; the cap
  just gives the pipeline enough headroom that interactions with the
  per-file writableChunkLimit and the go-fuse MaxWrite batching don't
  wedge a single-handle writer on a slow runner.
- Wrap every os.WriteFile in a writeWithTimeout helper that dumps every
  live goroutine on timeout. If this ever re-regresses, CI surfaces
  the actual stuck goroutines instead of a 45-minute walltime.
- Also guard the concurrent-writer goroutines with the same timeout +
  stack dump.

The in-package unit test TestWriteBufferCap_SharedAcrossPipelines
remains the deterministic, controlled verification of the blocking
Reserve/Release path — this e2e test is now a smoke test for
correctness and absence of deadlocks through a real FUSE mount, which
is all it should be.

* fix: address PR #9066 review — idempotent FreeReference, subtest watchdog, larger single-handle test

FreeReference on SealedChunk now early-returns when referenceCounter is
already <= 0. The existing == 0 body guard already made side effects
idempotent, but the counter itself would still decrement into the
negatives on a double-call — ugly and a latent landmine for any future
caller that does math on the counter. Make double-call a strict no-op.

test(fuse): per-subtest watchdog + larger single-handle test

- Add runSubtestWithWatchdog and wrap every TestWriteBufferCap subtest
  with a 3-minute deadline. Individual writes were already
  timeout-wrapped but the readback loops and surrounding bookkeeping
  were not, leaving a gap where a subtest body could still hang. On
  watchdog fire, every live goroutine is dumped so CI surfaces the
  wedge instead of a 45-minute walltime.

- Bump testLargeFileUnderCap from 12 MiB → 20 MiB (10 chunks) to
  exceed the 16 MiB cap (8 slots) again and actually exercise
  Reserve/Release backpressure on a single file handle. The earlier
  e2e hang was under much tighter params (-writeBufferSizeMB=4,
  -concurrentWriters=4, writable limit 4); with the current loosened
  config the pressure is gentle and the goroutine-dump-on-timeout
  safety net is in place if it ever regresses.

Declined: adding an observable peak-Used() assertion to the e2e test.
The mount runs as a subprocess so its in-process WriteBufferAccountant
state isn't reachable from the test without adding a metrics/RPC
surface. The deterministic peak-vs-cap verification already lives in
the in-package unit test TestWriteBufferCap_SharedAcrossPipelines.
Recorded this rationale inline in TestWriteBufferCap's doc comment.

* test(fuse): capture mount pprof goroutine dump on write-timeout

The previous run (24388549058) hung on LargeFileUnderCap and the
test-side dumpAllGoroutines only showed the test process — the test's
syscall.Write is blocked in the kernel waiting for FUSE to respond,
which tells us nothing about where the MOUNT is stuck. The mount runs
as a subprocess so its in-process stacks aren't reachable from the
test.

Enable the mount's pprof endpoint via -debug=true -debug.port=<free>,
allocate the port from the test, and on write-timeout fetch
/debug/pprof/goroutine?debug=2 from the mount process and log it. This
gives CI the only view that can actually diagnose a write-buffer
backpressure deadlock (writer goroutines blocked on Reserve, uploader
goroutines stalled on something, etc).

Kept fileSize at 20 MiB so the Linux CI run will still hit the hang
(if it's genuinely there) and produce an actionable mount-side dump;
the alternative — silently shrinking the test below the cap — would
lose the regression signal entirely.

* review: constructor-inject accountant + subtest watchdog body on main

Two PR-#9066 review fixes:

1. NewUploadPipeline now takes the WriteBufferAccountant as a
   constructor parameter; SetWriteBufferAccountant is removed. In
   practice the previous setter was only called once during
   newMemoryChunkPages, before any goroutine could touch the
   pipeline, so there was no actual race — but constructor injection
   makes the "accountant is fixed at construction time" invariant
   explicit and eliminates the possibility of a future caller
   mutating it mid-flight. All three call sites (real + two tests)
   updated; the legacy TestUploadPipeline passes a nil accountant,
   preserving backward-compatible unlimited-mode behavior.

2. runSubtestWithWatchdog now runs body on the subtest main goroutine
   and starts a watcher goroutine that only calls goroutine-safe t
   methods (t.Log, t.Logf, t.Errorf). The previous version ran body
   on a spawned goroutine, which meant any require.* or writeWithTimeout
   t.Fatalf inside body was being called from a non-test goroutine —
   explicitly disallowed by Go's testing docs. The watcher no longer
   interrupts body (it can't), so body must return on its own —
   which it does via writeWithTimeout's internal 90s timeout firing
   t.Fatalf on (now) the main goroutine. The watchdog still provides
   the critical diagnostic: on timeout it dumps both test-side and
   mount-side (via pprof) goroutine stacks and marks the test failed
   via t.Errorf.

* fix(mount): IsComplete must detect coverage across adjacent intervals

Linux FUSE caps per-op writes at FUSE_MAX_PAGES_PER_REQ (typically
1 MiB on x86_64) regardless of go-fuse's requested MaxWrite, so a
2 MiB chunk filled by a sequential writer arrives as two adjacent
1 MiB write ops. addInterval in ChunkWrittenIntervalList does not
merge adjacent intervals, so the resulting list has two elements
{[0,1M], [1M,2M]} — fully covered, but list.size()==2.

IsComplete previously returned `list.size() == 1 &&
list.head.next.isComplete(chunkSize)`, which required a single
interval covering [0, chunkSize). Under that rule, chunks filled by
adjacent writes never reach IsComplete==true, so maybeMoveToSealed
never fires, and the chunks sit in writableChunks until
FlushAll/close. SaveContent handles the adjacency correctly via its
inline merge loop, so uploads work once they're triggered — but
IsComplete is the gate that triggers them.

This was a latent bug: without the write-buffer cap, the overflow
path kicks in at writableChunkLimit (default 128) and force-seals
chunks, hiding the leak. #9066's -writeBufferSizeMB adds a tighter
global cap, and with 8 slots / 20 MiB test, the budget trips long
before overflow. The writer blocks in Reserve, waiting for a slot
that never frees because no uploader ever ran — observed in the CI
run 24390596623 mount pprof dump: goroutine 1 stuck in
WriteBufferAccountant.Reserve → cond.Wait, zero uploader goroutines
anywhere in the 89-goroutine dump.

Walk the (sorted) interval list tracking the furthest covered
offset; return true if coverage reaches chunkSize with no gaps. This
correctly handles adjacent intervals, overlapping intervals, and
out-of-order inserts. Added TestIsComplete_AdjacentIntervals
covering single-write, two adjacent halves (both orderings), eight
adjacent eighths, gaps, missing edges, and overlaps.

* test(fuse): route mount glog to stderr + dump mount on any write error

Run 24392087737 (with the IsComplete fix) no longer hangs on Linux —
huge progress. Now TestWriteBufferCap/LargeFileUnderCap fails with
'close(...write_buffer_cap_large.bin): input/output error', meaning
a chunk upload failed and pages.lastErr propagated via FlushData to
close(). But the mount log in the CI artifact is empty because weed
mount's glog defaults to /tmp/weed.* files, which the CI upload step
never sees, so we can't tell WHICH upload failed or WHY.

Add -logtostderr=true -v=2 to MountOptions so glog output goes to
the mount process's stderr, which the framework's startProcess
redirects into f.logDir/mount.log, which the framework's DumpLogs
then prints to the test output on failure. The -v=2 floor enables
saveDataAsChunk upload errors (currently logged at V(0)) plus the
medium-level write_pipeline/upload traces without drowning the log
in V(4) noise.

Also dump MOUNT goroutines on any writeWithTimeout error (not just
timeout). The IsComplete fix means we now get explicit errors
instead of silent hangs, and the goroutine dump at the error moment
shows in-flight upload state (pending sealed chunks, retry loops,
etc) that a post-failure log alone can't capture.
2026-04-14 07:47:35 -07:00
..
2025-07-16 12:43:08 -07:00
2025-07-16 12:43:08 -07:00
2025-07-16 12:43:08 -07:00
2025-10-13 18:05:17 -07:00

SeaweedFS FUSE Integration Testing Framework

Overview

This directory contains a comprehensive integration testing framework for SeaweedFS FUSE operations. The current SeaweedFS FUSE tests are primarily performance-focused (using FIO) but lack comprehensive functional testing. This framework addresses those gaps.

⚠️ Current Status

Note: Due to Go module conflicts between this test framework and the parent SeaweedFS module, the full test suite currently requires manual setup. The framework files are provided as a foundation for comprehensive FUSE testing once the module structure is resolved.

Working Components

  • Framework design and architecture (framework.go)
  • Individual test file structure and compilation
  • Test methodology and comprehensive coverage
  • Documentation and usage examples
  • ⚠️ Full test suite execution (requires Go module isolation)

Verified Working Test

cd test/fuse_integration
go test -v simple_test.go

Current Testing Gaps Addressed

1. Limited Functional Coverage

  • Current: Only basic FIO performance tests
  • New: Comprehensive testing of all FUSE operations (create, read, write, delete, mkdir, rmdir, permissions, etc.)

2. No Concurrency Testing

  • Current: Single-threaded performance tests
  • New: Extensive concurrent operation tests, race condition detection, thread safety validation

3. Insufficient Error Handling

  • Current: Basic error scenarios
  • New: Comprehensive error condition testing, edge cases, failure recovery

4. Missing Edge Cases

  • Current: Simple file operations
  • New: Large files, sparse files, deep directory nesting, many small files, permission variations

Framework Architecture

Core Components

  1. framework.go - Test infrastructure and utilities

    • FuseTestFramework - Main test management struct
    • Automated SeaweedFS cluster setup/teardown
    • FUSE mount/unmount management
    • Helper functions for file operations and assertions
  2. basic_operations_test.go - Fundamental FUSE operations

    • File create, read, write, delete
    • File attributes and permissions
    • Large file handling
    • Sparse file operations
  3. directory_operations_test.go - Directory-specific tests

    • Directory creation, deletion, listing
    • Nested directory structures
    • Directory permissions and rename operations
    • Complex directory scenarios
  4. concurrent_operations_test.go - Concurrency and stress testing

    • Concurrent file and directory operations
    • Race condition detection
    • High-frequency operations
    • Stress testing scenarios

Key Features

Automated Test Environment

framework := NewFuseTestFramework(t, DefaultTestConfig())
defer framework.Cleanup()
require.NoError(t, framework.Setup(DefaultTestConfig()))
  • Automatic cluster setup: Master, Volume, Filer servers
  • FUSE mounting: Proper mount point management
  • Cleanup: Automatic teardown of all resources

Configurable Test Parameters

config := &TestConfig{
    Collection:   "test",
    Replication:  "001", 
    ChunkSizeMB:  8,
    CacheSizeMB:  200,
    NumVolumes:   5,
    EnableDebug:  true,
    MountOptions: []string{"-allowOthers"},
}

Rich Assertion Helpers

framework.AssertFileExists("path/to/file")
framework.AssertFileContent("file.txt", expectedContent)
framework.AssertFileMode("script.sh", 0755)
framework.CreateTestFile("test.txt", []byte("content"))

Test Categories

1. Basic File Operations

  • Create/Read/Write/Delete: Fundamental file operations
  • File Attributes: Size, timestamps, permissions
  • Append Operations: File appending behavior
  • Large Files: Files exceeding chunk size limits
  • Sparse Files: Non-contiguous file data

2. Directory Operations

  • Directory Lifecycle: Create, list, remove directories
  • Nested Structures: Deep directory hierarchies
  • Directory Permissions: Access control testing
  • Directory Rename: Move operations
  • Complex Scenarios: Many files, deep nesting

3. Concurrent Operations

  • Multi-threaded Access: Simultaneous file operations
  • Race Condition Detection: Concurrent read/write scenarios
  • Directory Concurrency: Parallel directory operations
  • Stress Testing: High-frequency operations

4. Error Handling & Edge Cases

  • Permission Denied: Access control violations
  • Disk Full: Storage limit scenarios
  • Network Issues: Filer/Volume server failures
  • Invalid Operations: Malformed requests
  • Recovery Testing: Error recovery scenarios

Usage Examples

Basic Test Run

# Build SeaweedFS binary
make

# Run all FUSE tests
cd test/fuse_integration
go test -v

# Run specific test category
go test -v -run TestBasicFileOperations
go test -v -run TestConcurrentFileOperations

Custom Configuration

func TestCustomFUSE(t *testing.T) {
    config := &TestConfig{
        ChunkSizeMB:  16,           // Larger chunks
        CacheSizeMB:  500,          // More cache
        EnableDebug:  true,         // Debug output
        SkipCleanup:  true,         // Keep files for inspection
    }
    
    framework := NewFuseTestFramework(t, config)
    defer framework.Cleanup()
    require.NoError(t, framework.Setup(config))
    
    // Your tests here...
}

Debugging Failed Tests

config := &TestConfig{
    EnableDebug:  true,     // Enable verbose logging
    SkipCleanup:  true,     // Keep temp files for inspection
}

Advanced Features

Performance Benchmarking

func BenchmarkLargeFileWrite(b *testing.B) {
    framework := NewFuseTestFramework(t, DefaultTestConfig())
    defer framework.Cleanup()
    require.NoError(t, framework.Setup(DefaultTestConfig()))
    
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        // Benchmark file operations
    }
}

Custom Test Scenarios

func TestCustomWorkload(t *testing.T) {
    framework := NewFuseTestFramework(t, DefaultTestConfig())
    defer framework.Cleanup()
    require.NoError(t, framework.Setup(DefaultTestConfig()))
    
    // Simulate specific application workload
    simulateWebServerWorkload(t, framework)
    simulateDatabaseWorkload(t, framework)
    simulateBackupWorkload(t, framework)
}

Integration with CI/CD

GitHub Actions Example

name: FUSE Integration Tests
on: [push, pull_request]

jobs:
  fuse-tests:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: actions/setup-go@v3
      with:
        go-version: '1.24'
    
    - name: Install FUSE
      run: sudo apt-get install -y fuse
    
    - name: Build SeaweedFS
      run: make
    
    - name: Run FUSE Tests
      run: |
        cd test/fuse_integration
        go test -v -timeout 30m

Docker Testing

FROM golang:1.24
RUN apt-get update && apt-get install -y fuse
COPY . /seaweedfs
WORKDIR /seaweedfs
RUN make
CMD ["go", "test", "-v", "./test/fuse_integration/..."]

Comparison with Current Testing

Aspect Current Tests New Framework
Operations Covered Basic FIO read/write All FUSE operations
Concurrency Single-threaded Multi-threaded stress tests
Error Scenarios Limited Comprehensive error handling
File Types Regular files only Large, sparse, many small files
Directory Testing None Complete directory operations
Setup Complexity Manual Docker setup Automated cluster management
Test Isolation Shared environment Isolated per-test environments
Debugging Limited Rich debugging and inspection

Benefits

1. Comprehensive Coverage

  • Tests all FUSE operations supported by SeaweedFS
  • Covers edge cases and error conditions
  • Validates behavior under concurrent access

2. Reliable Testing

  • Isolated test environments prevent test interference
  • Automatic cleanup ensures consistent state
  • Deterministic test execution

3. Easy Maintenance

  • Clear test organization and naming
  • Rich helper functions reduce code duplication
  • Configurable test parameters for different scenarios

4. Real-world Validation

  • Tests actual FUSE filesystem behavior
  • Validates integration between all SeaweedFS components
  • Catches issues that unit tests might miss

Future Enhancements

1. Extended FUSE Features

  • Extended attributes (xattr) testing
  • Symbolic link operations
  • Hard link behavior
  • File locking mechanisms

2. Performance Profiling

  • Built-in performance measurement
  • Memory usage tracking
  • Latency distribution analysis
  • Throughput benchmarking

3. Fault Injection

  • Network partition simulation
  • Server failure scenarios
  • Disk full conditions
  • Memory pressure testing

4. Integration Testing

  • Multi-filer configurations
  • Cross-datacenter replication
  • S3 API compatibility while mounted
  • Backup/restore operations

Getting Started

  1. Prerequisites

    # Install FUSE
    sudo apt-get install fuse  # Ubuntu/Debian
    brew install macfuse       # macOS
    
    # Build SeaweedFS
    make
    
  2. Run Tests

    cd test/fuse_integration
    go test -v
    
  3. View Results

    • Test output shows detailed operation results
    • Failed tests include specific error information
    • Debug mode provides verbose logging

This framework represents a significant improvement in SeaweedFS FUSE testing capabilities, providing comprehensive coverage, real-world validation, and reliable automation that will help ensure the robustness and reliability of the FUSE implementation.