From owner-freebsd-stable@FreeBSD.ORG Wed Apr 16 03:28:53 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 34B2C37B401; Wed, 16 Apr 2003 03:28:53 -0700 (PDT) Received: from mail.r.caley.org.uk (82-41-209-16.cable.ubr12.edin.blueyonder.co.uk [82.41.209.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C32643F75; Wed, 16 Apr 2003 03:28:51 -0700 (PDT) (envelope-from rjc@caley.org.uk) Received: from pele.r.caley.org.uk (pele.r.caley.org.uk [10.0.0.12]) by mail.r.caley.org.uk (8.12.6/8.12.6) with ESMTP id h3GASnXj093442; Wed, 16 Apr 2003 11:28:49 +0100 (BST) (envelope-from rjc@bast.r.caley.org.uk) Received: from pele.r.caley.org.uk (localhost [127.0.0.1]) by pele.r.caley.org.uk (8.12.6/8.12.6) with ESMTP id h3GASnFl051393; Wed, 16 Apr 2003 11:28:49 +0100 (BST) (envelope-from rjc@bast.r.caley.org.uk) Received: (from rjc@localhost) by pele.r.caley.org.uk (8.12.6/8.12.6/Submit) id h3GASnQQ051390; Wed, 16 Apr 2003 11:28:49 +0100 (BST) (envelope-from rjc@bast.r.caley.org.uk) X-Authentication-Warning: pele.r.caley.org.uk: rjc set sender to rjc@bast.r.caley.org.uk using -f Sender: rjc@caley.org.uk To: Marko Zec References: <200304121438.h3CEct41030991@lurza.secnetix.de> <3E9840B8.F00E018F@tel.fer.hr> From: Richard Caley In-Reply-To: <3E9840B8.F00E018F@tel.fer.hr> Date: 16 Apr 2003 11:28:49 +0100 Message-ID: <87smsiohwe.fsf@pele.r.caley.org.uk> Lines: 26 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-fs@freebsd.org 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:28:53 -0000 In article <3E9840B8.F00E018F@tel.fer.hr>, Marko Zec (mz) writes: mz> I agree that additional tunable for controlling fsync() behavior couldn't hurt, mz> however as explained in previous note I see the fsync() as the most common mz> initiator of disk spinnups, so a method for suppressing it must be made mz> available, otherwise the whole patch wouldn't make much sense... Would it make sense to make the fsync behaviour a per-process choice? That way certain system processes could, if this delay behaviour is enabled, use the null fsync. For instance, if syslog is one of the things causing annoying spin-ups, then the user could tell syslog not to really fsync, trading forensic information in the event of a crash for battery life. Additionally there could be a really_really_fysnc call to be used to make certain programs delay-aware. Eg, it might be acceptable for my emacs checkpointing not to fsync, again I'm trading losing a little more work in the event of a crash for battery life, but when I explicitly save, I am saying I want that stuff on disk and stable NOW, and damn battery. -- Mail me as MYFIRSTNAME@MYLASTNAME.org.uk _O_ |<