arnavsharma990 commented on issue #20120:
URL: https://github.com/apache/nuttx/issues/20120#issuecomment-5667489449
I did a deeper review of the current VFS and filesystem implementations,
including FAT, tmpfs, SPIFFS, littlefs, and NFS, to determine whether the
lifetime management pattern from #20101 warrants a common abstraction.
My current conclusion is that **a generic mechanism does not appear
justified at this point**.
The important distinction is that although several filesystems use some
combination of reference counting and deferred deletion, their ownership and
identity models are different:
- **FAT**
- Uses a canonical `fat_shared_s` object keyed by directory sector/index.
- An open file holds a reference to the shared object.
- Unlink marks the object as pending while allowing the directory entry to
be reused.
- The FAT cluster chain is reclaimed when the final reference is released.
- The implementation also requires FAT-specific handling for
rename/re-keying, cursor invalidation, truncation, and cluster management.
- **tmpfs**
- Uses a heap object whose identity is already represented by the object
pointer.
- Open instances can share the same object and maintain references.
- Unlink marks the object as `UNLINKED` and removes its directory
reference.
- Existing final-release logic already defers reclamation until the last
reference.
- It does not require FAT-style keying, re-keying, or cursor invalidation.
- **SPIFFS**
- Uses per-open file objects, with `dup()` sharing the existing object.
- Supports an `UNLINKED` state and deferred cleanup.
- However, independent `open()` calls do not canonicalize to the same
shared object.
- Its ownership model therefore differs from FAT.
- **littlefs**
- Uses a per-open `lfs_file` with reference handling for duplicated
descriptors.
- Unlink is delegated to the littlefs core.
- Its copy-on-write semantics handle the underlying lifetime requirements.
- It does not require the same shared-object mechanism as FAT.
- **NFS**
- Maintains per-open client/server handle state.
- Reference counting primarily handles duplicated descriptors.
- Removal is performed through an immediate `REMOVE` RPC.
- The lifetime issue here is fundamentally different because it involves
distributed/server-side coherence rather than local filesystem object
reclamation.
The existing VFS `struct file` / `f_refs` handling already provides the
required descriptor-level sharing for `dup()`, `dup2()`, and `fcntl()`
duplication. The remaining lifetime semantics are therefore filesystem-specific.
Based on this investigation, I don't currently see a second filesystem with
sufficiently similar ownership and identity semantics to justify a reusable
abstraction.
A generic helper would either become tightly coupled to FAT's
keyed/re-keyable model, or be reduced to a generic `refcount + pending` helper
whose savings appear too small to justify the additional API, locking,
configuration, and maintenance overhead.
I don't think an implementation PR for #20120 would provide enough benefit
at this stage.
If a future filesystem encounters the same *canonical shared object +
unlink-pending + final-reference reclamation* requirement, that would provide a
much stronger basis for revisiting a common mechanism.
Thanks!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
