From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 08:03:57 2011 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 078B41065677; Sat, 26 Nov 2011 08:03:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 97D2A8FC12; Sat, 26 Nov 2011 08:03:55 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAQ83qgN055798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Nov 2011 10:03:52 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAQ83pWT059912; Sat, 26 Nov 2011 10:03:51 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAQ83pHt059911; Sat, 26 Nov 2011 10:03:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Nov 2011 10:03:51 +0200 From: Kostik Belousov To: Kirk McKusick Message-ID: <20111126080351.GD50300@deviant.kiev.zoral.com.ua> References: <20111123194444.GE50300@deviant.kiev.zoral.com.ua> <201111260725.pAQ7PDow056289@chez.mckusick.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aWoxrSeOuqWGYfm5" Content-Disposition: inline In-Reply-To: <201111260725.pAQ7PDow056289@chez.mckusick.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 08:03:57 -0000 --aWoxrSeOuqWGYfm5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 25, 2011 at 11:25:13PM -0800, Kirk McKusick wrote: > Kostik, >=20 > You are entirely correct when you say that the requirement for > SU and SU+J is that it requires that notification of a disk-write > complete mean that the data is on the disk (stable). The problem > that arises is that (apparently) some tag-queue implementations > report back that tags have been written when in fact they have > not been written.=20 Right, and my belief that real hardware is not much affected, except probably some ultra-cheap and old ATA disks. Another issue is broken-by-design 'drivers' which authors do not understand the environment they programming for. >=20 > I believe that they only way to ensure that a tagged request is > on stable store is to send a BIO_BARRIER request to the disk. The > BIO_BARRIER request is not supposed to return until all I/O > requests that were sent down prior to the BIO_BARRIER have been > committed to stable store. >=20 > If in fact the disk hardware lies about tag completion, my > proposed way for SU and SU+J to use BIO_BARRIER is to send > one down periodically (say every 100ms) and then defer processing > any I/O completions from before the barrier request until the > BIO_BARRIER completes. Since most SU activity is going on in > background, the delay should not be too noticable. The main > place where it would likely show up is in fsync which could be > delayed for up to the period (100ms). For such cases, the fsync > should issue its own BIO_BARRIER once it has initiated all of > its required I/O. I do not see how this proposal change much, except limiting potential havoc to the last 100ms of system operation. In fact, reordering, besides causing fs consistency problems, may cause the security issues as well [*]. If user data is written into the reused blocks, but metadata update was ordered after data write, we can end with the arbitrary override of the sensititive authorization or accounting information. * I expect some people going wonky at this point and immediately remove corresponding driver from ports. P.S. Sorry for being grumpy. --aWoxrSeOuqWGYfm5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7QnWcACgkQC3+MBN1Mb4h2CgCcC2ob7hPtDcYfGQFZZzuoUEeb 4sMAoMwBNpMp/oCd4EbZNiCV+jUn17pX =7dr3 -----END PGP SIGNATURE----- --aWoxrSeOuqWGYfm5--