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

Add simulated disk Io #15

Open
mcches opened this issue Aug 18, 2022 · 2 comments
Open

Add simulated disk Io #15

mcches opened this issue Aug 18, 2022 · 2 comments
Labels
enhancement New feature or request

Comments

@mcches
Copy link
Contributor

mcches commented Aug 18, 2022

Is your feature request related to a problem? Please describe.
No. This is new functionality.

Describe the solution you'd like
Hosts have an Io concept today, but it is just network. Add the ability to write/read to/from disk, and have this state persist across host restarts.

@mcches mcches added the enhancement New feature or request label Jan 12, 2023
@battesonb
Copy link
Member

I'd like to pick this up. I have a partially implemented proof-of-concept on my fork from some tinkering this weekend using an in-memory virtual file system. I see a few "trophies" for getting this fully implemented.

  1. Generic filesystem
    This is just a virtual filesystem over the generic parts of the API. The tokio tests can be grabbed and rewritten in turmoil style (example) -- although I'd suggest extra testing around the errors. There are some cases where this API bleeds into std and I don't really think there's a nice solution for that. For example the Metadata struct used by tokio is from std. In some cases we can use the std type, such as Path -- but it does have functions which won't work (like is_file).

  2. File system interjections
    Similar to the hold and repair methods, we'd need some way to inject errors into the file system. I'm not sure whether this is needed for the first implementation, but separating them would require a version bump. I'd suggest separating simply because of the surface area of the fs module. A big-bang PR might not be the way to go for good feedback.

  3. OS-specific implementations
    I currently have some of these just panic with the unimplemented!() macro, but a correct implementation would include these as well. For example, the different permission models across operating systems.

@mcches
Copy link
Contributor Author

mcches commented Oct 23, 2023

For (2), I don't think we need a version bump since this would be additive. It's probably totally different. We'll want an io failure rate with the same rng behavior as net and then the ability to corrupt files and stuff like that.

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

No branches or pull requests

2 participants