Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to efficiently implement a drop file system #73

Open
lizelive opened this issue Apr 28, 2022 · 1 comment
Open

How to efficiently implement a drop file system #73

lizelive opened this issue Apr 28, 2022 · 1 comment

Comments

@lizelive
Copy link

lizelive commented Apr 28, 2022

Defining a drop file system as a read only pass through file system that silently ignores write operations.

My plan is for open read, we'd do the open and forward the reads. For create / write we open behave like /dev/null
For read directory, if the directory exists read it normally
Otherwise treat it like an empty directory.

Reading and writing to a file descriptor that doesn't exist is undefined thinking that it does not throw an error, instead behaves like /dev/null unless it's faster to throw an error.

Getting information for files the don't exist Acts like /dev/null

Would be a lot easier if pass through was a trait with default imitation that actually does pass through.

I was thinking I would be to have a pass through in my struct and forward valid operations and mask failures. Also always disable write caching. My understanding is that their is only one trait I need to implement and that's BackendFileSystem or FileSystem

I was looking at the pass through file system defined here, as well as https://github.com/libfuse/libfuse/blob/master/example/passthrough_hp.cc My understanding is that passthrough_hp.cc doesn't do any unnecessary copies.

  1. Does the pass through do unnecessary copies?
  2. Do I always need synchronous io?
  3. Is there anything like memory mapping that I have to worry about? I really don't want the user to be able to write to the underlying FS under any circumstance.
  4. Should I disable write cashing?
  5. Would it be more performant to implement a black hole (acts acts like an empty directory and ignores all write and creation) and then set up an overlay?
  6. BackendFileSystem vs FileSystem
@lizelive
Copy link
Author

I'm sad Rust doesn't have inheritance would make this cleaner.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant