On Wed, Sep 26, 2018 at 07:10:55PM +0100, Alan Cox wrote: > In almost all cases you don't care so you wouldn't use it. In those cases > where it might matter it's almost always the case that a reader won't > consume it before it hits the media. > > That's why I suggested having an fbarrier() so you can explicitly say 'in > the even that case does happen then stall and write it'. It's kind of > lazy fsync. That can be used with almost no cost by things like mail > daemons. How could mail daemons use it? They *have* to do an fsync() before they send a 2xx SMTP return code. There are plenty of other dependencies besides read --- for example, if you write a mp3 file, and then write the playlist.m3u file, maybe the barrier requirement is "if playlist.m3u survives after the crash, all of the mp3 files mentioned in it must completely written out to disk". So I'm not sure how useful a fbarrier(2) would be in practice. > Another way given that this only really makes sense with locks > is to add that fbarrier notion as a file locking optional semantic so you > can 'unlock with barrier' and 'lock with barrier honoured' I'm not sure what you're suggesting? - Ted
