From owner-freebsd-fs@FreeBSD.ORG  Sat Nov 26 17:12:35 2011
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
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 434321065670;
	Sat, 26 Nov 2011 17:12:35 +0000 (UTC)
	(envelope-from mckusick@mckusick.com)
Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235])
	by mx1.freebsd.org (Postfix) with ESMTP id 238078FC12;
	Sat, 26 Nov 2011 17:12:34 +0000 (UTC)
Received: from chez.mckusick.com (localhost [127.0.0.1])
	by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id pAQHCY8G081783;
	Sat, 26 Nov 2011 09:12:34 -0800 (PST)
	(envelope-from mckusick@chez.mckusick.com)
Message-Id: <201111261712.pAQHCY8G081783@chez.mckusick.com>
To: lev@FreeBSD.org
In-reply-to: <147455115.20111126115248@serebryakov.spb.ru> 
Date: Sat, 26 Nov 2011 09:12:34 -0800
From: Kirk McKusick <mckusick@mckusick.com>
X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY
	autolearn=failed version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com
Cc: freebsd-fs@FreeBSD.org
Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with
	softupdates)? 
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Nov 2011 17:12:35 -0000

Kostik has it right. The requirement for SU and SU+J is simply
that the underlying I/O subsystem not issue bio_done on a write
until it is on stable store. If the I/O subsystem wants to cache
it for a while (multiple seconds) before writing it to disk that
is fine (SU thinks in terms of 30-second intervals). The only
thing that SU requires is that the subsystem NOT lie by issuing
the bio_done before it has committed the data to disk. Perhaps
what we need is a "delay acknowledgement until done' flag to make
this clear. My previous suggestion of using BIO_BARRIER was just
a way to try and enforce this behavior. Based on the performance
and other issues raised, this is clearly a bad idea. So, my question
to you is how can we reliably get the underlying systems to not lie
to us about the stability of our I/O request?

	Kirk McKusick