From owner-freebsd-fs@FreeBSD.ORG Wed Sep 1 10:34:47 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5133B10656BF for ; Wed, 1 Sep 2010 10:34:47 +0000 (UTC) (envelope-from cracauer@koef.zs64.net) Received: from koef.zs64.net (koef.zs64.net [IPv6:2001:470:1f0b:105e::1e6]) by mx1.freebsd.org (Postfix) with ESMTP id 0FF9A8FC08 for ; Wed, 1 Sep 2010 10:34:46 +0000 (UTC) Received: from koef.zs64.net (koef.zs64.net [IPv6:2001:470:1f0b:105e::1e6]) by koef.zs64.net (8.14.4/8.14.4) with ESMTP id o81AYjDw024121; Wed, 1 Sep 2010 12:34:45 +0200 (CEST) (envelope-from cracauer@koef.zs64.net) Received: (from cracauer@localhost) by koef.zs64.net (8.14.4/8.14.4/Submit) id o81AYilx024120; Wed, 1 Sep 2010 06:34:44 -0400 (EDT) (envelope-from cracauer) Date: Wed, 1 Sep 2010 06:34:44 -0400 From: Martin Cracauer To: Kostik Belousov Message-ID: <20100901103444.GA22129@cons.org> References: <20100830225841.GA9363@cons.org> <20100831160840.GA74125@icarus.home.lan> <20100831230728.GA36384@cons.org> <20100901064805.GF2396@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100901064805.GF2396@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org, Martin Cracauer Subject: Re: fsync(2) and on-disk write-back cache X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 10:34:47 -0000 Kostik Belousov wrote on Wed, Sep 01, 2010 at 09:48:05AM +0300: > On Tue, Aug 31, 2010 at 07:07:28PM -0400, Martin Cracauer wrote: > > Benjamin Kaduk wrote on Tue, Aug 31, 2010 at 12:12:04PM -0400: > > > On Tue, 31 Aug 2010, Jeremy Chadwick wrote: > > > > > > >On Mon, Aug 30, 2010 at 06:58:42PM -0400, Martin Cracauer wrote: > > > >>I always assumed the answer to this question is "of course": > > > >> > > > >>When doing an fsync (waiting for the commit), do we actually tell the > > > >>disk to flush the on-disk write-back cache (if that is in use) to the > > > >>platters? > > > >> > > > >>I just went down some code paths in both FreeBSD and Linux and in both > > > >>cases the paths for fsync quickly disappear in the generic > > > >>block-by-block flushing code that is also used for regular (non-fsync) > > > >>flushing. I didn't see anything aware of the on-disk cache. > > > > > > > >I don't have an authoritative answer to your question, but this thread > > > >seems to imply there's a relation between fsync() and an intentional > > > >disk flush (BIO_FLUSH). I'm sure when BIO_FLUSH is called depends on > > > >the filesystem as well. > > > > I just went the for-dummies way and annotated all relevant BIO_FLUSH > > places with debug print statements. They don't seem to be called when > > doing an fsync on a file in a local filesystem. ufs (no softupdates) > > -> old-style SCSI disk. > > > > I'll snoop around some more, try it on ZFS/SATA and do some timing > > tests. > Be assured that all variants of UFS (sync, async, SU, SU+J) do not > call BIO_FLUSH. With a ZFS on SATA it looks different. ad_strategy gets called to queue BIO_FLUSH three times (for a single-block fsync). However, those calls are after fsync completes and returned to the called. And I still can't see how the disk would communicate individual block's status (on platter or not), all I see is global commands to flush all the cache (and I don't think that is synchronous). Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/