Memory Inefficiency during Metadata Operations

[raj-prince]

---

Issue: Memory Inefficiency during Metadata Operations

• The Constraint: Because /dev/fuse is packet-oriented, the daemon must always read incoming requests into a maximum-sized buffer (1MB + pageSize), even for tiny metadata requests (like getattr or lookup < 128 bytes).
• The Inefficiency: Currently, this large buffer is kept checked out of the pool for the entire duration of the request's execution (until the filesystem replies).
• The Impact: Under high concurrency (e.g., 100 concurrent metadata requests), this wastes ~100 MB of memory in inactive, blocked buffers.

---

Solution: Early Buffer Release

• The Insight: Once a metadata request is converted into a Go struct (like LookUpInodeOp), all strings are copied to the Go heap. The fuseops.Op struct retains no pointers to the original InMessage buffer.
• The Optimization:
  1. Decouple State: Store the FUSE request ID (unique) and opCode directly in the opState context, so we don't need to query InMessage later.
  2. Early Recycle: In ReadOp(), check if the operation is a data payload operation (ReadFileOp, WriteFileOp, or SetXattrOp).
     • If no (it's a metadata operation), immediately return the InMessage buffer to the pool (within microseconds of the read) and store nil in the context.
     • If yes, keep it alive for zero-copy.
  3. Safe Reply: Update Reply() to use the stored ID/opcode and safely skip recycling if the buffer was already early-released.

---

Impact

• Memory Footprint: Drops from ~100MB to 0 bytes for in-flight metadata operations. Buffers are recycled instantly.
• Performance: Retains 100% zero-copy paths for heavy read/write payloads.
• Zero API Changes: Bounded entirely within the library's internal connection logic. No filesystem code needs to change.