With default_permissions (the mount default) the kernel enforces unix
permission bits from the getattr/lookup attributes before it ever calls
Open, Create, or Mknod. The mount was re-checking permissions in
AcquireHandle and createRegularFile anyway, which duplicated the kernel's
work and kept the supplementary-group lookup on the per-file hot path.
Gate only the mode-bit access check on default_permissions being off, so
a non-root copy does no permission work on open/create. createRegularFile
still loads the parent to validate it exists, since the create RPC skips
the filer-side parent check. With default_permissions off the mount
remains the sole enforcer, so the full check still runs.
* mount: cache supplementary group IDs to improve non-root access performance
* mount: clear supplementary group cache between tests and add cache verification test
* mount: add docstrings and benchmarks for supplementary group cache
* mount: add performance test demonstrating cache effectiveness
* mount: add TTL-based cache expiry for supplementary group IDs (5-minute refresh)
* fix(mount): flush dirty handles on Release when kernel skipped Flush
The FUSE protocol allows the kernel to send Release without a preceding
Flush; file handles that reach Release with dirtyMetadata=true (notably
deferred creates that never saw any write) would then have their pending
filer CreateEntry dropped on the floor, leaving the mount and filer out
of sync.
Detect dirty handles in Release and call doFlush before tearing the
handle down. Skip the fallback when an async flush is already pending so
we don't double-submit. Flock-unlock Releases stay on the synchronous
path so close()-time serialization is preserved.
Adds TestReleaseFlushesDirtyCreateIfFlushWasSkipped covering the
create-without-flush path.
* address review: drop racy dirty-flag peek, let doFlush self-gate
fh.dirtyMetadata / fh.asyncFlushPending are written from the periodic
metadata flusher and async flush worker under fhLockTable, so the
unsynchronized read in Release was a data race per the reviewer.
Just call doFlush unconditionally on every Release; it already fast-
paths the clean case (dirtyPages.FlushData early-returns when hasWrites
is false, and the dirty-metadata branch short-circuits), so the extra
call after a normal Flush is cheap while the no-Flush-before-Release
path still recovers a deferred create.
* fix(mount): serialize hard-link mutations on HardLinkId
syncHardLinkSiblings stamps every sibling of a hard-link to
authoritativeEntry.HardLinkCounter, and the caller computes that value
as entry.HardLinkCounter - 1 (Unlink) or entry.HardLinkCounter + 1
(Link) from a cached entry read before the filer mutation. With
concurrent Unlinks on different links of the same file, both callers
observe the same pre-decrement counter, the filer's atomic blob
decrement lands correctly, but both then stamp their siblings to
counter-1 — leaving the mount metacache one higher than the authoritative
blob.
Serialize Link and Unlink on string(HardLinkId) via a new
hardLinkLockTable on WFS, and re-load the entry under the lock so the
second caller sees the updated sibling counter its predecessor just
wrote before computing its own delta. First-link races (empty
HardLinkId on the source) are a separate pre-existing issue and are
not addressed here.
Full pjdfstest suite still passes (235 files, 8803 tests).
* fix(mount): abort on stale pre-lock entry after HardLinkId lock
Review follow-up: if maybeLoadEntry fails after acquiring the
hardLinkLockTable lock, the prior revision silently fell back to the
pre-lock snapshot, reintroducing the stale-base update the lock is
meant to prevent.
- Unlink: treat fuse.ENOENT as success (the file was already removed by
the thread that held the lock before us) and propagate any other
error.
- Link: abort with the returned status so we never derive the next
HardLinkCounter from a stale source entry.
* fix(mount): re-resolve Link source alias under HardLinkId lock
Review follow-up: Link resolved oldEntryPath from in.Oldnodeid before
waiting on the HardLinkId lock. A concurrent Unlink that held the same
lock could remove the specific alias we picked pre-lock while leaving
other sibling hard links for the same inode intact. The post-lock
maybeLoadEntry then returned ENOENT even though the source inode was
still reachable.
Call GetPath(in.Oldnodeid) again under the lock to pick whichever
alias is still active, refresh oldParentPath, and only return ENOENT
if no sibling survived.
* mount: add option to show system entries
* address gemini code review's suggested changes
* rename flag from -showSystemEntries to -includeSystemEntries
* meta_cache: purge hidden system entries on filer events
---------
Co-authored-by: Chris Lu <chris.lu@gmail.com>
* mount: defer file creation gRPC to flush time for faster small file writes
When creating a file via FUSE Create(), skip the synchronous gRPC
CreateEntry call to the filer. Instead, allocate the inode and build
the entry locally, deferring the filer create to the Flush/Release path
where flushMetadataToFiler already sends a CreateEntry with chunk data.
This eliminates one synchronous gRPC round-trip per file during creation.
For workloads with many small files (e.g. 30K files), this reduces the
per-file overhead from ~2 gRPC calls to ~1.
Mknod retains synchronous filer creation since it has no file handle
and thus no flush path.
* mount: use bounded worker pool for async flush operations
Replace unbounded goroutine spawning in writebackCache async flush
with a fixed-size worker pool backed by a channel. When many files
are closed rapidly (e.g., cp -r of 30K files), the previous approach
spawned one goroutine per file, leading to resource contention on
gRPC/HTTP connections and high goroutine overhead.
The worker pool size matches ConcurrentWriters (default 128), which
provides good parallelism while bounding resource usage. Work items
are queued into a buffered channel and processed by persistent worker
goroutines.
* mount: fix deferred create cache visibility and async flush race
Three fixes for the deferred create and async flush changes:
1. Insert a local placeholder entry into the metadata cache during
deferred file creation so that maybeLoadEntry() can find the file
for duplicate-create checks, stat, and readdir. Uses InsertEntry
directly (not applyLocalMetadataEvent) to avoid triggering the
directory hot-threshold eviction that would wipe the entry.
2. Fix race in ReleaseHandle where asyncFlushWg.Add(1) and the
channel send happened after pendingAsyncFlushMu was unlocked.
A concurrent WaitForAsyncFlush could observe a zero counter,
close the channel, and cause a send-on-closed panic. Move Add(1)
before the unlock; keep the send after unlock to avoid deadlock
with workers that acquire the same mutex during cleanup.
3. Update TestCreateCreatesAndOpensFile to flush the file handle
before verifying the CreateEntry gRPC call, since file creation
is now deferred to flush time.
* mount: implement create for rsync temp files
* mount: move access implementation out of unsupported
* mount: tighten access checks
* mount: log access group lookup failures
* mount: reset dirty pages on truncate
* mount: tighten create and root access handling
* mount: handle existing creates before quota checks
* mount: restrict access fallback when group lookup fails
When lookupSupplementaryGroupIDs returns an error, the previous code
fell through to checking only the "other" permission bits, which could
overgrant access. Require both group and other permission classes to
satisfy the mask so access is never broader than intended.
* mount: guard against nil entry in Create existing-file path
maybeLoadEntry can return OK with a nil entry or nil Attributes in
edge cases. Check before dereferencing to prevent a panic.
* mount: reopen existing file on create race without O_EXCL
When createRegularFile returns EEXIST because another process won the
race, and O_EXCL is not set, reload the winner's entry and open it
instead of propagating the error to the caller.
* mount: check parent directory permission in createRegularFile
Verify the caller has write+search (W_OK|X_OK) permission on the
parent directory before creating a file. This applies to both
Create and Mknod. Update test fixture mount mode to 0o777 so the
existing tests pass with the new check.
* mount: enforce file permission bits in AcquireHandle
Map the open flags (O_RDONLY/O_WRONLY/O_RDWR) to an access mask and
call hasAccess before handing out a file handle. This makes
AcquireHandle the single source of truth for mode-based access
control across Open, Create-existing, and Create-new paths.
---------
Co-authored-by: Copilot <copilot@github.com>
Chris Lu