arnavsharma990 opened a new issue, #20120:
URL: https://github.com/apache/nuttx/issues/20120

   ### Is your feature request related to a problem? Please describe.
   
   This issue was identified while fixing 
[#20037](https://github.com/apache/nuttx/issues/20037), where the FAT 
filesystem could release a file's cluster chain when the file was unlinked 
while still open.
   
   The FAT fix in [#20101](https://github.com/apache/nuttx/pull/20101) 
introduced filesystem-local shared state to track the lifetime of an open file 
independently of individual file descriptors.
   
   While investigating the same lifetime semantics across other filesystems, I 
found that NuttX currently has no common mechanism for filesystems that require 
shared open-file state:
   
   - **tmpfs** already maintains shared per-file state with reference counting 
and an unlinked state, and correctly defers reclamation until the last 
reference is released.
   - **littlefs** handles removal of open files through its existing 
copy-on-write and orphan handling mechanisms and does not appear to require 
such an abstraction.
   - **NFS** appears to have a related lifetime-management gap: open state is 
maintained per `open()` operation, while removal is performed immediately 
without a shared open-file lifetime mechanism or silly-rename handling.
   
   This suggests that open-file lifetime management is currently implemented 
independently by each filesystem, with no reusable mechanism for filesystems 
that need shared state across open, `dup()`, unlink, and close operations.
   
   ### Describe the solution you'd like
   
   I would like to explore an **opt-in mechanism for shared open-file lifetime 
management** that can be used by filesystems that require it, without making it 
a mandatory part of the VFS.
   
   The common pattern could provide a shared per-filesystem object that is 
looked up or created when a file is opened, reference-counted across `open()` 
and `dup()`, marked for deferred deletion when the file is unlinked, and 
reclaimed when the final reference is released.
   
   The exact API, ownership model, and placement are intentionally left open 
for discussion. The `fat_shared_s` implementation introduced in 
[#20101](https://github.com/apache/nuttx/pull/20101) provides a concrete 
example of this lifetime-management pattern, while NFS appears to be a 
potential second use case.
   
   The mechanism should remain optional so that filesystems that already manage 
object lifetime correctly do not need to adopt it, and filesystems that do not 
use it should not incur additional `struct file`, RAM, or runtime overhead.
   
   If this direction is considered useful, I would be happy to prototype a 
minimal implementation and evaluate it with an additional filesystem.
   
   ### Describe alternatives you've considered
   
   - **Continue implementing lifetime management independently in each 
filesystem.** This avoids introducing a common abstraction, but requires each 
filesystem to independently solve the same open, `dup()`, unlink, and 
final-close lifetime problems.
   
   - **Introduce a mandatory generic inode/object cache in the VFS.** This 
would provide a common mechanism, but appears broader than necessary. `tmpfs` 
and `littlefs` demonstrate that filesystems can already provide correct 
lifetime semantics using their own internal models. Making such infrastructure 
mandatory could also impose unnecessary memory or runtime costs on small 
targets.
   
   - **Keep the current FAT-local implementation and address other filesystems 
independently.** This is viable, but the experience from #20037/#20101 suggests 
there may be value in identifying a small reusable abstraction for filesystems 
that encounter the same class of lifetime-management problem.
   
   ### Verification
   
   - [x] I have verified before submitting the report.


-- 
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]

Reply via email to