-
Notifications
You must be signed in to change notification settings - Fork 3k
bd: Add sync function to the block device API #5926
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
Conversation
/** Ensure data on storage is in sync with the driver * * @return 0 on success or a negative error code on failure */ virtual int sync()
Required to garuntee that data is flushed all the way down to the disk level when a file is synced or closed.
Since (at present) all the block devices write through buffers, sync essentially will be empty call, but what will be expected in future from sync call and what type of block device will need it? |
FTL? If I understand correctly, all of the block devices that we have don't require a sync, as they're currently implemented, but this is adding the function for when a block devices does need one, correct? |
@cmonr is correct. @deepikabhavnani I'm not exactly sure what else to add since the actual sync implementation is dependent on the block device. One example: Has a low-priority thread for writing out data, sync could escalate that thread to the current priority and block until all data has been written out. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
/morph build |
Build : SUCCESSBuild number : 996 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 687 |
Test : SUCCESSBuild number : 817 |
Right now, all block devices must effectively sync data on read/program, or else the power resilience gauruntees of littlefs don't hold true.
This is fine with the current state of the block device, which just write through any buffers provided (since external flash is much cheaper than internal caching and speed is a secondary concern to code footprint). However, in order to provide a decent FTL a syncing mechanic is necessary to ensure storage is up to date with in-flight data.
cc @deepikabhavnani