-
Notifications
You must be signed in to change notification settings - Fork 214
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
storage: abstract disk I/O #660
Comments
Isn't that only the disk backend depends on file operations? |
Yes. But even disk backend has two modes -- pure in-memory mode (for testing, where files are stored in a hash map), and real on-disk mode. |
If we can abstract all disk operations to use a trait like ObjectStore, we can prevent unwanted writes to disk in in-memory secondary storage. |
I think we should use the real on-disk mode in testing, to make sure we are correctly using the system fs API. Data path can be redirected to ramfs/tmpfs to speed up. |
Later we can also introduce the simulation testing, where all fs API will be mocked to an in-memory simulator. |
I switch to pure in-memory mode because tmpfs is slow 🤣 fsync and manifest write will add 1s latency to every disk test case, which looks weird. Maybe I can try switch off fsync for all writes (even manifest), and maybe things will work. |
🤣 okay let's stay in memory mode for efficiency. |
Currently, we have create_dir, etc. everywhere. We'd better have a single interface to operate files on disk, so as to support in-memory / disk / object store backends.
The text was updated successfully, but these errors were encountered: