From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 10:11:30 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C68621065672; Wed, 27 Oct 2010 10:11:30 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 892668FC08; Wed, 27 Oct 2010 10:11:30 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id D2568E7FB5; Wed, 27 Oct 2010 11:11:29 +0100 (BST) Received: from unknown (client-81-107-142-135.midd.adsl.virginmedia.com [81.107.142.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Wed, 27 Oct 2010 11:11:29 +0100 (BST) Date: Wed, 27 Oct 2010 11:11:24 +0100 From: Bruce Cran To: perryh@pluto.rain.com Message-ID: <20101027111124.00007450@unknown> In-Reply-To: <4cc7ea44.ApOaxS8Xr4Sxu+0x%perryh@pluto.rain.com> References: <20101026213618.GA3013@freebsd.org> <4cc7ea44.ApOaxS8Xr4Sxu+0x%perryh@pluto.rain.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, ivoras@freebsd.org Subject: Re: fsync(2) manual and hdd write caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 10:11:30 -0000 On Wed, 27 Oct 2010 02:00:51 -0700 perryh@pluto.rain.com wrote: > Short of mounting synchronously, with the attendant performance > hit, would it not make sense for fsync(2) to issue ATA_FLUSHCACHE > or SCSI "SYNCHRONIZE CACHE" after it has finished writing data > to the drive? Surely the low-level capability to issue those > commands must already exist, else we would have no way to safely > prepare for power off. mounting synchronously won't help, will it? As I understand it that just makes sure that data is sent straight to disk and not left in memory; the data will still be stored in the HDD cache for a while. -- Bruce Cran