jim owens <jowens@xxxxxx> wrote on 05/29/2008 11:46:10 AM: > Bryan Henderson wrote: > >>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). > > > > > > I don't get it. What would be the value of emitting the barrier? > > In both cases the FS must flush the drive write cache. > > So which of Jamie's traps got you ... Must have been where he assumes we think of a barrier as something that causes a flush of the drive write cache. That actually didn't cross my mind in reading the proposal; it's probably some context I missed from earlier in the thread. If the idea is for fdatasync() to have that sync-to-platter function, fdatasync() should just tell the block layer to sync previously written data (now in the drive cache) to the platter; it has an interface for that, doesn't it? A barrier is rather the opposite: it doesn't say to sync some data. It says _don't_ sync some data. I can believe it has a side effect of cleaning the drive's write cache, but I wouldn't want to depend on it for that. The other question -- whether fdatasync ought to sync the data all the way to the platter instead of just to the drive -- is separate. Hasn't that been discussed before? Unfortunately, there are lots of levels of storage stability and POSIX just gives us the means to specify one, and the two sides of that interface have been locked in a battle for as long as I can remember to control the stability/performance tradeoff. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
