From owner-freebsd-stable@FreeBSD.ORG Wed Apr 16 03:11:37 2003 Return-Path: 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 9E9F837B401; Wed, 16 Apr 2003 03:11:37 -0700 (PDT) Received: from HAL9000.homeunix.com (12-233-57-131.client.attbi.com [12.233.57.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 013C643FAF; Wed, 16 Apr 2003 03:11:37 -0700 (PDT) (envelope-from das@FreeBSD.org) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.5) with ESMTP id h3GABa9E001264; Wed, 16 Apr 2003 03:11:36 -0700 (PDT) (envelope-from das@FreeBSD.org) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.5/Submit) id h3GABaTM001263; Wed, 16 Apr 2003 03:11:36 -0700 (PDT) (envelope-from das@FreeBSD.org) Date: Wed, 16 Apr 2003 03:11:36 -0700 From: David Schultz To: Marko Zec Message-ID: <20030416101136.GA868@HAL9000.homeunix.com> Mail-Followup-To: Marko Zec , freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org, mckusick@McKusick.COM References: <3E976EBD.C3E66EF8@tel.fer.hr> <20030414101935.GB18110@HAL9000.homeunix.com> <3E9C5975.43755858@tel.fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E9C5975.43755858@tel.fer.hr> cc: freebsd-fs@FreeBSD.org cc: mckusick@McKusick.COM cc: freebsd-stable@FreeBSD.org Subject: Re: PATCH: Forcible delaying of UFS (soft)updates X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 10:11:38 -0000 On Tue, Apr 15, 2003, Marko Zec wrote: > David Schultz wrote: > > > For instance, you could > > have fsync() push the appropriate dirty buffers out to a separate > > cache, then commit the contents of the cache in the order of the > > fsyncs when the disk is next active. > > Huh... such a concept would still break fsync() semantics. Note that the > original patch also ensures dirty buffers get flushed if / when the disk spins > up, even before the delay timer gets expired. I didn't say it wouldn't still break fsync() semantics; it doesn't. However, you could guarantee that data are in a consistent state with my proposal. On the other hand, the more I think about the details, the more I think this could be more of a pain than it's worth. > > > - The fiddling with rushjob seems rather arbitrary. You can probably > > just let the existing code increment it as necessary and force a sync > > if the value gets too high. > > If rushjob is would not be used for forcing prompt synching, the original code > could not guarantee the sync to occur immediately. Instead, the synching could > be further delayed for up to 30 seconds, which is not desirable if our major > design goal is to do as much disk I/O as possible in a small time interval and > leave the disk idle otherwise. I was referring to all the places where rushjob is set to or incremented by syncer_maxdelay. AFAIK, it should never be that large. I don't think you want to overload a low memory handling mechanism with the task of syncing the disk.