Re:Linux's fsync() woes are getting some attention
by deathanatos on Tuesday March 11, 2014 @01:25AM
(#7377598)
While a "notify me when this write completes" (but don't feel the need to rush) might be useful, I think it'd be more useful to be able to push both write A and write B to the kernel, along with the condition of "A before B". You not only get the write ordering, but the kernel gets full knowledge of what's going on. Perhaps it could use this to write A and B together (but journaled at the FS level) to guarantee the order, whereas a simple write-complete notification implies at least two writes, and the latency of doing such.
[ Parent
| on HN ]
Re:Linux's fsync() woes are getting some attention
by bodyfour on Tuesday March 11, 2014 @11:41AM
(#7379900)
The two-write operation you propose is simpler, but you're losing a lot of generality. Specifically, think about:
* I want to notify a network client that its write is done
* When this write is done, I want to delete a temporary file
Re:Linux's fsync() woes are getting some attention
by deathanatos on Tuesday March 11, 2014 @05:59PM
(#7382475)
Good points — there's definitely a place for a write barrier. It may be that a simple write barrier, while not as efficient for this use case, might be generally more useful.
For your second point, if you take my initial "write B depends on the completion of write A", and extend it allow arbitrary kernel commands to depend on others, then you could still do that, (delete B depends on write A), however, things are probably too complex at this point, and a simple write barrier is better.