From owner-freebsd-stable  Thu Jul 25 13:51:53 2002
Delivered-To: freebsd-stable@freebsd.org
Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 8B95237B400
	for <freebsd-stable@FreeBSD.ORG>; Thu, 25 Jul 2002 13:51:51 -0700 (PDT)
Received: from alcanet.com.au (mail2.alcanet.com.au [203.62.196.17])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 226FE43E4A
	for <freebsd-stable@FreeBSD.ORG>; Thu, 25 Jul 2002 13:51:50 -0700 (PDT)
	(envelope-from peter.jeremy@alcatel.com.au)
Received: from gsmx07.alcatel.com.au (IDENT:root@localhost.localdomain [127.0.0.1])
	by alcanet.com.au (8.12.4/8.12.4/Alcanet1.3) with ESMTP id g6PKpTiv026351;
	Fri, 26 Jul 2002 06:51:30 +1000
Received: from gsmx07.alcatel.com.au (localhost [127.0.0.1])
	by gsmx07.alcatel.com.au (8.12.3/8.12.3) with ESMTP id g6PKpT2h056473;
	Fri, 26 Jul 2002 06:51:29 +1000 (EST)
	(envelope-from peter.jeremy@alcatel.com.au)
Received: (from jeremyp@localhost)
	by gsmx07.alcatel.com.au (8.12.3/8.12.3/Submit) id g6PKpToQ056472;
	Fri, 26 Jul 2002 06:51:29 +1000 (EST)
Date: Fri, 26 Jul 2002 06:51:29 +1000
From: Peter Jeremy <peter.jeremy@alcatel.com.au>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: "Mark W. Krentel" <krentel@dreamscape.com>,
	freebsd-stable@FreeBSD.ORG
Subject: Re: 4.6-RC: Glacial speed of dump backups
Message-ID: <20020726065129.Q38313@gsmx07.alcatel.com.au>
Mail-Followup-To: Matthew Dillon <dillon@apollo.backplane.com>,
	"Mark W. Krentel" <krentel@dreamscape.com>,
	freebsd-stable@FreeBSD.ORG
References: <200207240505.g6O550534455@dreamscape.com> <200207240513.g6O5Dljx025899@apollo.backplane.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <200207240513.g6O5Dljx025899@apollo.backplane.com>; from dillon@apollo.backplane.com on Tue, Jul 23, 2002 at 10:13:47PM -0700
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-stable.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-stable>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-stable>
X-Loop: FreeBSD.ORG

On 2002-Jul-23 22:13:47 -0700, Matthew Dillon <dillon@apollo.backplane.com> wrote:
>    Now FreeBSD's dump program does in fact do a sync() itself,
>    right in its main().  This is probably why you didn't see the
>    problem w/ FreeBSD.  If FreeBSD's dump program did not do that
>    sync() your test would probably not have worked.
>
>    If linux's sync() does not sync the filesystem then it's a bug in
>    linux's sync().

Tradionally, sync(2) just initiates the cache flush, it does not block
until the flush completes (hence the "type sync 3 times on your KSR33
before halting" mantra).  This is even documented under BUGS in our
sync(2) man page.

Our dump(8) does a sync() and then carries right on merrily.  There's
nothing ensuring that the cache is completely flushed.  Since the
first few dump passes relate to metadata (which is traditionally
updated synchronously) its highly unlikely that the cache flush won't
have completed by the time dump gets around to dumping the actual
data.  For both soft updates and async mounts, it would seem a bit of
a gamble since the metadata may not be flushed before dump gets around
to looking at it.  (And softupdates guarantees that the disk is
consistent at a point in time, it doesn't guarantee that an inode read
now is consistent with a data block read 30 minutes later).

That said, Mark's problem suggests that a dirty data block isn't
being flushed - which does look more like a cache flush bug.

Peter

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message