Re: fdatasync/barriers (was : [Bug 421482] Firefox 3 uses fsync excessively)

[Timothy Shimmin <tes@sgi.com>]

Bryan Henderson wrote:
> jim owens <jowens@hp.com> 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