From owner-freebsd-stable Fri Mar 7 1: 0:39 2003 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 62C3B37B401 for ; Fri, 7 Mar 2003 01:00:38 -0800 (PST) Received: from HAL9000.homeunix.com (12-233-57-224.client.attbi.com [12.233.57.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA49B43FA3 for ; Fri, 7 Mar 2003 01:00:37 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id h2790XLT061193; Fri, 7 Mar 2003 01:00:33 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id h2790XsB061192; Fri, 7 Mar 2003 01:00:33 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Fri, 7 Mar 2003 01:00:33 -0800 From: David Schultz To: "Marc G. Fournier" Cc: freebsd-stable@FreeBSD.ORG Subject: Re: "leak" in softupdates? Message-ID: <20030307090033.GA61037@HAL9000.homeunix.com> Mail-Followup-To: "Marc G. Fournier" , freebsd-stable@FreeBSD.ORG References: <20030305204526.T38115@hub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030305204526.T38115@hub.org> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Marc G. Fournier : > OS is 4.8-RC FreeBSD 4.8-RC #38: Tue Mar 4 22:43:18 CST 2003 with a patch > from Tor Egge to fix a problem with how vnodes are kept track of and > reclaimed/reused ... Hmmm...did you run into the problem before applying the patch? I can't imagine softupdates getting several gigabytes behind. > I've tried doing a 'sync', figuring that maybe it would force all > outstanding writes to the drive, but that seems to make no difference > either ... By the way, sync(8) doesn't guarantee that all outstanding dependencies are written to disk. It does write out all buffers that can be written at the time sync is called, but while those buffers are being written, dependencies may be uncovered and more buffers may come along. Since it could potentially have to keep trying forever in the face of an infinite stream of requests, sync doesn't keep trying. You can guarantee that everything is flushed to disk (if even for a brief moment) by attempting to unmount the filesystem you want to sync (without -f). The unmount will fail because the filesystem is in use, but everything will be written out before it does. What I really don't understand is how you seem to manage to run into more bugs than everyone else. (FYI, the libc_r/KVA_PAGES bug is now fixed in -STABLE.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message