3 ms·
The api needs existing filesystems to have fdatasync_rangev functionality implemented. It is likely it would not avoid any complexity, just move it elsewhere.
by rini17 6y ago
The api needs existing filesystems to have fdatasync_rangev functionality implemented. It is likely it would not avoid any complexity, just move it elsewhere.
- jlokier 6y agoI agree with you, but the article puts in a polite request for filesystem changes already under "potential enhancements". My argument is if there were to be some work on potential enhancements that require kernel filesystem changes and syscall changes, fdatasync_rangev would be a more useful choice of enhancement, and probably easier to implement than fbarrier. Better for performance, user convenience (no more separate files), and more kinds of applications (e.g. VMs and other kinds of in-file data store). It's not as big as it sounds. fsync_range is already in FreeBSD, NetBSD and AIX, and Linux nearly got it too (there was a patch). (Linux got sync_file_range instead, which is not useful for this unfortunately despite the similar name.)