From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 23:28:56 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 BB14A106566B; Tue, 26 Oct 2010 23:28:56 +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 557558FC1D; Tue, 26 Oct 2010 23:28:56 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 9D016E801E; Wed, 27 Oct 2010 00:28:55 +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 00:28:53 +0100 (BST) Date: Wed, 27 Oct 2010 00:28:49 +0100 From: Bruce Cran To: Ivan Voras Message-ID: <20101027002849.00002772@unknown> In-Reply-To: References: <20101026213618.GA3013@freebsd.org> 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 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: Tue, 26 Oct 2010 23:28:56 -0000 On Wed, 27 Oct 2010 01:19:18 +0200 Ivan Voras wrote: > fsync(2) actually does behave as advertised, "auses all modified data > and attributes of fd to be moved to a permanent storage device". It > is the problem of the "permanent storage device" if it caches this > data further. http://www.opengroup.org/onlinepubs/009695399/functions/fsync.html at first suggests it should flush write caches, but does allow for implementations that don't: "The fsync() function is intended to force a physical write of data from the buffer cache, and to assure that after a system crash or other failure that all data up to the time of the fsync() call is recorded on the disk." ... "In the middle ground between these extremes, fsync() might or might not actually cause data to be written where it is safe from a power failure." -- Bruce Cran