Files
seaweedfs/test/fuse_integration/POSIX_IMPLEMENTATION_ROADMAP.md
T
Chris LuandDevin 7c980774e7 FUSE mount: add posix compliance reports (#7183)
* fuse integration: add POSIX compliance test suite

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* ci: add posix-compliance workflow

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* fuse integration: skip non-executable weed path candidates

* fuse integration: size readv buffer to the written segment

* fuse integration: reference posix_Makefile explicitly in recursive make calls

GNU make does not propagate -f through MAKEFLAGS, so bare $(MAKE) re-read the default Makefile in this directory.

* fuse integration: fail posix test targets when go test fails

Every suite pipes go test through tee under /bin/sh, so the recipe status was tee's and test failures stayed green. Run recipes under bash -o pipefail and emit the color escapes with printf since bash echo does not expand them.

* fuse integration: run only benchmarks in benchmark-posix

go test -bench=. without -run also executes the whole suite, mixing compliance output into the benchmark log.

* fuse integration: emit single-number test counts in reports

grep -c prints 0 and exits nonzero when nothing matches, so '|| echo 0' produced two lines that broke the expr arithmetic and JSON fields. awk prints exactly one count either way.

* fuse integration: skip the sendfile test on macOS

macOS sendfile(2) only accepts a socket destination; the test copies into a regular file and always gets ENOTSOCK.

* fuse integration: honor TestConfig and own only self-started resources

NewFuseTestFramework dropped its config argument and Cleanup read a fresh
DefaultTestConfig, so SkipCleanup never did anything. Cleanup also skipped
teardown whenever TEST_SKIP_CLUSTER_SETUP was set, even when TEST_MOUNT_POINT
was empty and Setup had started the cluster itself. The framework now keeps
the config it was built with, runs external-mount tests inside a per-run work
dir under the mount, and only skips teardown when an external mount was
actually used.

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* fuse integration: pass the debug flag before the subcommand

-v is a weed global flag; appended after master/volume/filer/mount it lands
on the subcommand flagset, which rejects it and the process dies at flag
parsing whenever EnableDebug is on.

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* fuse integration: require a real mount before running tests

Setup creates the mount point before weed mount starts, so statting and
listing it succeeded on the plain directory and tests ran against local
disk whenever the mount was slow or died. waitForMount now waits until the
mount point's device id differs from its parent's.

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* fuse integration: resolve the weed binary to an absolute path

The started processes run with cmd.Dir at the framework's temp dir, so a
relative candidate like ../weed no longer resolves. Prefer PATH, then probe
the usual build outputs and return absolute paths only.

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* fuse integration: build the external test work dir with MkdirTemp

The suite staged cloned tools and generated scripts under a predictable
/tmp path another user could pre-create and swap mid-run.

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* fuse integration: use the pjdfstest tree setup-pjdfstest installs

The test gated on a pjdfstest binary in PATH but then proved a suite it
cloned itself, so a tree installed by make setup-pjdfstest was never found.
Look for the built suite under external_tools first, then clone into the
work dir as before.

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* ci: require a real mount before posix tests

The wait loop fell back to listing the mount point, which passes on the
directory created before weed mount runs — a dead or slow mount meant the
suite exercised local disk. Only mountpoint counts now, and a dead mount
process fails fast instead of timing out.

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* ci: collect failure logs before cleanup deletes them

The always-on cleanup step removed /tmp/seaweedfs before the failure-only
debug step could copy the service logs, so failed runs uploaded nothing.
Run cleanup after log collection.

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* fuse integration: point MOUNT_POINT at TEST_MOUNT_POINT

Targets that work against MOUNT_POINT (pjdfstest, nfstest, fio configs)
ignored TEST_MOUNT_POINT and ran against the local-disk default while the
go tests used the external mount.

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* fuse integration: skip the permission-denied check as root

Root bypasses mode-bit checks, so writing the read-only file succeeded and
the assertion failed in root-run environments like containers.

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* fuse integration: align the posix docs with the suite

The doc listed a docker-test-posix target and make variables that do not
exist, and ran go test against single files that cannot compile alone. The
roadmap also still claimed the platform-specific tests this suite now
implements were all skipped.

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* fuse integration: honor SkipCleanup in the mini-based framework too

Same gap as the fuse-package framework: Cleanup read a fresh
DefaultTestConfig, so a test's SkipCleanup setting was ignored.

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* fuse integration: normalize config in Setup and clean the work dir too

Setup(nil) panicked on config.EnableDebug and external-mount Cleanup left
the temp dir behind; use the stored config for the start* calls and remove
tempDir alongside the external work dir.

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* ci: point external posix suites at the workflow FUSE mount

* fuse integration: create the fio target directory before running

* fuse integration: use unix.O_DIRECT instead of a hard-coded x86 value

0x4000 is O_DIRECT only on x86 and amd64; on arm64 it is O_DIRECTORY.
The test module already depends on golang.org/x/sys.

* fuse integration: run autoreconf and configure before building pjdfstest

A fresh pjdfstest clone is autotools-based and has no Makefile, so the
Go-side setup fallback always failed and the suite silently skipped.

* ci: require external posix tools only when setup installed them

setup-external-tools always exits 0 because each sub-target tolerates
failure, so POSIX_REQUIRE_EXTERNAL_TOOLS was set even with no tools
installed and the suite then hard-failed on the missing suites.

* ci: fail the posix workflow when the mount point is not a FUSE mount

The file write/read check passes on the plain directory created before
weed mount, so a dead mount let the whole suite grade the local disk.

* fuse integration: skip when the host has no FUSE device node

Setup failed the test outright on machines without /dev/fuse instead of
skipping; cover every suite entry point by skipping inside Setup.

* fuse integration: drop the chmod 666 /dev/fuse troubleshooting tip

World-writable device access is a security risk; the fuse group
membership on the line below is the safe fix.

* fuse integration: require go 1.21+ in check-go, not 1.20+

* fuse integration: refuse external suites on an unmounted path

* fuse integration: verify TEST_MOUNT_POINT is a real mount

* fuse integration: clean TEST_MOUNT_POINT before the parent-device check

filepath.Dir of a trailing-slash path returns the mount itself, so a mounted TEST_MOUNT_POINT ending in / was refused.

* fuse integration: detect WinFsp mounts on Windows in mountedAt

A directory mount is a reparse point and a drive mount is a volume root; a plain directory is now refused instead of accepted.

* fuse integration: strip a trailing slash off MOUNT_POINT in require-mounted

The mount-table grep fallback on hosts without mountpoint(8) would not match a slash-suffixed entry.

* fuse integration: require an external mount to be a FUSE filesystem

A device-ID boundary alone does not prove FUSE: a tmpfs mount would pass mountedAt and report its results as FUSE compliance. Check the filesystem type (statfs magic on linux, fstypename on the BSDs); platforms without a check keep the mount and write verification.

---------

Co-authored-by: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
2026-10-22 14:37:03 -07:00

7.9 KiB

POSIX Compliance Implementation Roadmap

This document tracks the implementation status of POSIX features in the SeaweedFS FUSE mount compliance test suite and provides a roadmap for completing comprehensive POSIX compliance testing.

Overview

The platform-specific tests listed below are implemented; this document records the implementation plan that produced them, plus the one feature still pending.

Current Status

✅ Implemented Features

  • Basic file operations (create, read, write, delete)
  • Directory operations (mkdir, rmdir, rename)
  • File permissions and ownership
  • Symbolic and hard links
  • Basic I/O operations (seek, append, positioned I/O)
  • File descriptors and atomic operations
  • Concurrent access patterns
  • Error handling compliance
  • Timestamp operations

🚧 Partially Implemented

  • Cross-platform compatibility (basic implementation with platform-specific access time handling)
  • File sealing (still skipped; Linux-specific, pending)

✅ Implemented Platform-Specific Features

1. Extended Attributes (xattr)

Priority: High Platforms: Linux, macOS, FreeBSD

Status: Implemented

  • TestExtendedAttributes/SetExtendedAttribute
  • TestExtendedAttributes/ListExtendedAttributes
  • TestExtendedAttributes/RemoveExtendedAttribute

Implementation Plan:

// Linux implementation
//go:build linux
func setXattr(path, name string, value []byte) error {
    return syscall.Setxattr(path, name, value, 0)
}

// macOS implementation  
//go:build darwin
func setXattr(path, name string, value []byte) error {
    return syscall.Setxattr(path, name, value, 0, 0)
}

Required Files:

  • xattr_linux.go - Linux syscall implementations
  • xattr_darwin.go - macOS syscall implementations
  • xattr_freebsd.go - FreeBSD syscall implementations
  • xattr_unsupported.go - Fallback for unsupported platforms

2. Memory Mapping (mmap)

Priority: High Platforms: All POSIX systems

Status: Implemented

  • TestMemoryMapping/MemoryMappedRead
  • TestMemoryMapping/MemoryMappedWrite

Implementation Plan:

func testMmap(t *testing.T, filePath string) {
    fd, err := syscall.Open(filePath, syscall.O_RDWR, 0)
    require.NoError(t, err)
    defer syscall.Close(fd)
    
    // Platform-specific mmap implementation
    data, err := syscall.Mmap(fd, 0, size, syscall.PROT_READ|syscall.PROT_WRITE, syscall.MAP_SHARED)
    require.NoError(t, err)
    defer syscall.Munmap(data)
}

Required Files:

  • mmap_unix.go - Unix-like systems implementation
  • mmap_windows.go - Windows implementation (if needed)

3. Vectored I/O (readv/writev)

Priority: Medium Platforms: All POSIX systems

Status: Implemented

  • TestAdvancedIO/VectoredIO

Implementation Plan:

func testVectoredIO(t *testing.T, filePath string) {
    // Use syscall.Syscall for readv/writev
    // Linux: SYS_READV, SYS_WRITEV
    // Other platforms: platform-specific syscall numbers
}

4. Direct I/O

Priority: Medium
Platforms: Linux, some Unix variants

Status: Implemented

  • TestDirectIO/DirectIO

Implementation Plan:

//go:build linux
func testDirectIO(t *testing.T, filePath string) {
    fd, err := syscall.Open(filePath, syscall.O_RDWR|syscall.O_DIRECT, 0)
    // Test with aligned buffers
}

5. File Preallocation (fallocate)

Priority: Medium Platforms: Linux, some Unix variants

Status: Implemented

  • TestFilePreallocation/Fallocate

Implementation Plan:

//go:build linux
func testFallocate(t *testing.T, filePath string) {
    fd, err := syscall.Open(filePath, syscall.O_RDWR, 0)
    err = syscall.Syscall6(syscall.SYS_FALLOCATE, uintptr(fd), 0, 0, uintptr(size), 0, 0)
}

6. Zero-Copy Transfer (sendfile)

Priority: Low Platforms: Linux, FreeBSD, some Unix variants

Status: Implemented

  • TestZeroCopyTransfer/Sendfile

Implementation Plan:

//go:build linux
func testSendfile(t *testing.T, srcPath, dstPath string) {
    // Use syscall.Syscall for sendfile
    // Platform-specific implementations
}

7. File Sealing (Linux-specific)

Priority: Low Platforms: Linux only

Current Status: File sealing test is still skipped

  • TestFileSealing

Implementation Plan:

//go:build linux
func testFileSealing(t *testing.T) {
    // Use fcntl with F_ADD_SEALS, F_GET_SEALS
    // Test various seal types: F_SEAL_WRITE, F_SEAL_SHRINK, etc.
}

Implementation Strategy

Phase 1: Core Features (High Priority)

  1. Extended Attributes - Essential for many applications
  2. Memory Mapping - Critical for performance-sensitive applications

Phase 2: Advanced I/O (Medium Priority)

  1. Vectored I/O - Important for efficient bulk operations
  2. Direct I/O - Needed for database and high-performance applications
  3. File Preallocation - Important for preventing fragmentation

Phase 3: Specialized Features (Low Priority)

  1. Zero-Copy Transfer - Performance optimization feature
  2. File Sealing - Security feature, Linux-specific

Platform Support Matrix

Feature Linux macOS FreeBSD Windows Notes
Extended Attributes ✅ ✅ ✅ ❌ Different syscall signatures
Memory Mapping ✅ ✅ ✅ ✅ Standard POSIX
Vectored I/O ✅ ✅ ✅ ❌ readv/writev syscalls
Direct I/O ✅ ❌ ✅ ❌ O_DIRECT flag
fallocate ✅ ❌ ❌ ❌ Linux-specific
sendfile ✅ ❌ ✅ ❌ Platform-specific
File Sealing ✅ ❌ ❌ ❌ Linux-only

Development Guidelines

1. Platform-Specific Implementation Pattern

// feature_linux.go
//go:build linux
package fuse
func platformSpecificFunction() { /* Linux implementation */ }

// feature_darwin.go  
//go:build darwin
package fuse
func platformSpecificFunction() { /* macOS implementation */ }

// feature_unsupported.go
//go:build !linux && !darwin
package fuse
func platformSpecificFunction() { /* Skip or error */ }

2. Test Structure Pattern

func (s *POSIXExtendedTestSuite) TestFeature(t *testing.T) {
    if !isFeatureSupported() {
        t.Skip("Feature not supported on this platform")
        return
    }
    
    t.Run("FeatureTest", func(t *testing.T) {
        // Actual test implementation
    })
}

3. Error Handling

  • Use platform-specific error checking
  • Provide meaningful error messages
  • Gracefully handle unsupported features

Testing Strategy

1. Continuous Integration

  • Run tests on multiple platforms (Linux, macOS)
  • Use build tags to enable/disable platform-specific tests
  • Ensure graceful degradation on unsupported platforms

2. Feature Detection

  • Implement runtime feature detection where possible
  • Skip tests gracefully when features are unavailable
  • Log clear messages about skipped functionality

3. Documentation

  • Document platform-specific behavior
  • Provide examples for each implemented feature
  • Maintain compatibility matrices

Contributing

When implementing these features:

  1. Start with high-priority items (Extended Attributes, Memory Mapping)
  2. Follow the platform-specific pattern outlined above
  3. Add comprehensive tests for each feature
  4. Update this roadmap as features are implemented
  5. Document any platform-specific quirks or limitations

Future Enhancements

Beyond the current roadmap, consider:

  • File locking (flock, fcntl locks)
  • Asynchronous I/O (aio_read, aio_write)
  • File change notifications (inotify, kqueue)
  • POSIX ACLs (Access Control Lists)
  • Sparse file operations
  • File hole punching

References