3 ms·

I think most of those things are implementable in userspace with the right combination of O_TMPFILE, rename, fsync, fsync(dir), sync_file_range and io_uring. S

I think most of those things are implementable in userspace with the right combination of O_TMPFILE, rename, fsync, fsync(dir), sync_file_range and io_uring. So all that's needed is encapsulating it in a library that provides those different abstractions. Well ok, we could also use an additional flag for linkat() that allows atomically replacing the target to close that tiny window where a temporary file might get left behind after a crash.

vlovich123 3y ago
Actually, a good chunk of that is available via memfd + linkat. - Unit files: memfd, fdatasync, linkat, fsync(dir) - Temporary files. memfd, preferably within /tmp to avoid any disk I/O unless you have a particularly large file to buffer - Log files. This is trickier. Probably requires running on a fs that supports reflinks and creating a new memfd that’s a true clone of the original file, appending, & then replacing it. The one piece that is incompatible with this is that other file descriptors are stale and you have to reopen to see new data but that’s at odds with APIs available today - either readers can see partial writes or you have to have a new file. There have been proposals to allow buffering writes but delaying publishing the metadata acking the data but that hasn’t gone anywhere unfortunately. - Managed files. I’m not sure that completions are the right contract here because technically the kernel could defer that completion indefinitely whereas databases typical need some kind of latency bounds of “OK - I really want this to commit to disk nowish”.
- nh2 3y ago
  "memfd + linkat"? How shall that work? memfd is for files in RAM. linkat cannot get them onto disk. What you seem to have in mind is what the grandparent post already described: "O_TMPFILE + linkat".
  - vlovich123 3y ago
    Sorry that’s right. O_TMPFILE is indeed what I meant

vlovich123 3y ago

Actually, a good chunk of that is available via memfd + linkat. - Unit files: memfd, fdatasync, linkat, fsync(dir) - Temporary files. memfd, preferably within /tmp to avoid any disk I/O unless you have a particularly large file to buffer - Log files. This is trickier. Probably requires running on a fs that supports reflinks and creating a new memfd that’s a true clone of the original file, appending, & then replacing it. The one piece that is incompatible with this is that other file descriptors are stale and you have to reopen to see new data but that’s at odds with APIs available today - either readers can see partial writes or you have to have a new file. There have been proposals to allow buffering writes but delaying publishing the metadata acking the data but that hasn’t gone anywhere unfortunately. - Managed files. I’m not sure that completions are the right contract here because technically the kernel could defer that completion indefinitely whereas databases typical need some kind of latency bounds of “OK - I really want this to commit to disk nowish”.

nh2 3y ago
"memfd + linkat"? How shall that work? memfd is for files in RAM. linkat cannot get them onto disk. What you seem to have in mind is what the grandparent post already described: "O_TMPFILE + linkat".
- vlovich123 3y ago
  Sorry that’s right. O_TMPFILE is indeed what I meant