Bryan Henderson wrote: > 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? > blkdev_issue_flush() do you mean? --Tim -- 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
