Jörn Engel wrote: > > We're currently forcing a new commit if I_DIRTY_SYNC or > > I_DIRTY_DATASYNC (but not necessarily I_DIRTY_PAGES) is set. If > > I_DIRTY_SYNC really means "smudged" (I believe you but I'll want to go > > through the code and prove it to myself :-), > > Proving it to yourself is good advice indeed. I'm sure it used to mean > "smudged" in 2.4.0 time. Whether any changes since have damaged that > property I haven't checked. I noticed fdatasync() doing a full fsync(), and had a look at those flags a few kernels ago, to implement fdatasync(). I wasn't convinced the flags were being used in that way, but now I don't remember why. So, yes, do check what they mean _now_. And then, please, make us all happy and implement fdatasync() :-) Here's a thought for someone implementing fdatasync(). If a database uses O_DIRECT writes (typically with aio), then wants data which it's written to be committed to the hard disk platter, and the filesystem is mounted "barrier=1" - should it call fdatasync()? Should that emit the barrier? If another application uses normal (not O_DIRECT) writes, and then _is delayed_ so long that kernel writeback occurs and all cache is clean, and then calls fdatasync(), should that call emit a barrier in that case? (Answers imho: yes and yes). > > (And then, we should rename things to more sane names. :-) Please, yes! The names made sense instinctively, until I looked at the code then they didn't :-) -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
