From owner-freebsd-fs@FreeBSD.ORG Tue Aug 31 14:21:46 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 C65B01065679 for ; Tue, 31 Aug 2010 14:21:46 +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 890E48FC0A for ; Tue, 31 Aug 2010 14:21: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 o7VELjNY030391; Tue, 31 Aug 2010 16:21: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 o7VELjVt030390; Tue, 31 Aug 2010 10:21:45 -0400 (EDT) (envelope-from cracauer) Date: Tue, 31 Aug 2010 10:21:45 -0400 From: Martin Cracauer To: Gary Jennejohn Message-ID: <20100831142144.GA26989@cons.org> References: <20100830225841.GA9363@cons.org> <20100831113851.6d449628@ernst.jennejohn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100831113851.6d449628@ernst.jennejohn.org> 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: Tue, 31 Aug 2010 14:21:46 -0000 Gary Jennejohn wrote on Tue, Aug 31, 2010 at 11:38:51AM +0200: > On Mon, 30 Aug 2010 18:58:42 -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 may be wrong, but it seems to me that the actual cache flush on the > disk is handled at a very low level - in the drivers. > > At least I'm pretty certain that e.g. the ahci code sends flush commands > to the disks. But does it wait for confirmation of completion? >From what I have seen in the code, the path for fsync(2) quickly merges with the code paths for regular flush (e.g. buffer full enough). fsync does wait for the underlying flush of the blocks in question, but that doesn't tell me whether that waits for the disk to confirm "on platter". So either all code paths wait for the data to be on platter or none. I can't think that all code waits for completion, because then the disk write performance would be the same with cache on write-through (reads only) and write-back. Unless the code flushes larger chunks between AHCI flush commands. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/