From mboxrd@z Thu Jan 1 00:00:00 1970 From: jim owens Subject: Re: fdatasync/barriers (was : [Bug 421482] Firefox 3 uses fsync excessively) Date: Thu, 29 May 2008 14:46:10 -0400 Message-ID: <483EF9F2.1000408@hp.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org To: Bryan Henderson Return-path: Received: from g4t0017.houston.hp.com ([15.201.24.20]:39298 "EHLO g4t0017.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756190AbYE2SqR (ORCPT ); Thu, 29 May 2008 14:46:17 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 ... EMIT (SEND) the barrier, not OMIT. "all cache is clean": meaning KERNEL cache, not DRIVE cache. ? :) jim