| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| < | > | |||||
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | ||||
Choose skin
Michael K. Johnson
Post details: Maybe we don't need fsyncv() after all
In all the hullabaloo about ext4 having inconvenient semantics with respect to a crash in close temporal proximity to an application attempting to do an atomic rename to replace file contents, I had wondered whether to propose a single system call that could provide an array of file descriptors to fsync(); I'm not sure if that's "scatter fsync()" or "gather fsync()"... I'm not sure what it would be called; fsyncv() is a bit misleading relative to readv() and writev() but it was the closest I could come up with. And it was beginning to look like we were going to need a way to say "wait for all of these files to be synced" without having to serialize the synchronization of each file individually or starting lots and lots of threads.
Thankfully, Valerie Aurora has explained that common sense is going to win. My thanks to many creative and thoughtful Linux kernel hackers who have spent countless hours pondering the tradeoffs and inventing better solutions.
There may be reasonable use cases for fsyncv(), but fortunately, it looks like someone else gets to think them up, and it shouldn't be required for normal applications. Yay!