From owner-freebsd-hackers@FreeBSD.ORG  Wed Oct 27 10:18:48 2010
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
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 60E621065786
	for <freebsd-hackers@freebsd.org>; Wed, 27 Oct 2010 10:18:48 +0000 (UTC)
	(envelope-from freebsd-hackers@m.gmane.org)
Received: from lo.gmane.org (lo.gmane.org [80.91.229.12])
	by mx1.freebsd.org (Postfix) with ESMTP id 16D958FC13
	for <freebsd-hackers@freebsd.org>; Wed, 27 Oct 2010 10:18:47 +0000 (UTC)
Received: from list by lo.gmane.org with local (Exim 4.69)
	(envelope-from <freebsd-hackers@m.gmane.org>) id 1PB35d-0003xT-C2
	for freebsd-hackers@freebsd.org; Wed, 27 Oct 2010 12:18:41 +0200
Received: from lara.cc.fer.hr ([161.53.72.113])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <freebsd-hackers@freebsd.org>; Wed, 27 Oct 2010 12:18:41 +0200
Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <freebsd-hackers@freebsd.org>; Wed, 27 Oct 2010 12:18:41 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: freebsd-hackers@freebsd.org
From: Ivan Voras <ivoras@freebsd.org>
Date: Wed, 27 Oct 2010 12:18:31 +0200
Lines: 23
Message-ID: <ia8u9l$46j$1@dough.gmane.org>
References: <20101026213618.GA3013@freebsd.org>
	<ia7nln$piv$1@dough.gmane.org>	<4cc7ea44.ApOaxS8Xr4Sxu+0x%perryh@pluto.rain.com>
	<20101027111124.00007450@unknown>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US;
	rv:1.9.1.12) Gecko/20101018 Thunderbird/3.0.8
In-Reply-To: <20101027111124.00007450@unknown>
X-Enigmail-Version: 1.0.1
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
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Oct 2010 10:18:48 -0000

On 10/27/10 12:11, Bruce Cran wrote:
> 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.

Correct. The problem is actually pretty hard - since AFAIK SoftUpdates
doesn't have "checkpoints" in the sense that it groups writes and all
data "before" can guaranteed to be on-disk, the problem is *when* to
issue BIO_FLUSH requests. One possible solution is to simply decide on a
heuristic like: "ok, doing BIO_FLUSH all the time will destroy
performance, we will only do it for every metadata write". Possibly with
a sysctl tunable or per-mount option.