From owner-freebsd-stable@FreeBSD.ORG Sat Apr 12 07:39:01 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 B2A4C37B401 for ; Sat, 12 Apr 2003 07:39:00 -0700 (PDT) Received: from lurza.secnetix.de (lurza.secnetix.de [212.66.1.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 629A743FBF for ; Sat, 12 Apr 2003 07:38:59 -0700 (PDT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (mdazwt@localhost [127.0.0.1]) by lurza.secnetix.de (8.12.8p1/8.12.8) with ESMTP id h3CEcuB5030992 for ; Sat, 12 Apr 2003 16:38:57 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.12.8p1/8.12.8/Submit) id h3CEct41030991; Sat, 12 Apr 2003 16:38:55 +0200 (CEST) Date: Sat, 12 Apr 2003 16:38:55 +0200 (CEST) Message-Id: <200304121438.h3CEct41030991@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: X-Newsgroups: list.freebsd-stable User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.8-RELEASE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: PATCH: Forcible delaying of UFS (soft)updates X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2003 14:39:01 -0000 Marko Zec wrote: > Here's a patch against 4.8-RELEASE kernel that allows disk writes on > softupdates-enabled filesystems to be delayed for (theoretically) > arbitrarily long periods of time. The motivation for such updating > policy is surprisingly not purely suicidal - it can allow disks on > laptops to spin down immediately after I/O operations and stay idle for > longer periods of time, thus saving considerable amount of battery > power. It would be very cool if you could have different delay settings per filesystem. That would enable you to have a large delay on /tmp, a medium delay on /var, and the standard delay (i.e. more safety) on everything else. > - fsync() no longer flushes the buffers to disk, but returns immediately > instead; I see some issues with that. Better make that tunable separately (and probably default to off). > - invoking sync() causes flushing of softupdates buffers to follow > immediately, which was not the case before; That's cool. I always disliked the fact I had to type sync several times and still couldn't be sure that everything was really synced. (Yeah, I know, it's the way it works, it always worked like that, and it's documented to work like that ... but I still dislike it.) > - if one of the mounted filesystems becomes low on free space, which can > happen if lot of data is written to the FS but FS metadata buffers are > not updated to disk, flushing of all softupdates buffers is scheduled > automatically; That's cool, too. I've been bitten several times by the bogus "no space left on device", due to soft-updates delaying the freeing of file data. I assume that buffered data is also flushed to disk when the system runs low on RAM, right? (I'm not a VFS/VM expert, so that might be a stupid question.) > Nevertheless, my laptop runs without glitches for the last two weeks > with the extra delaying enabled, while happily achieving 5-10% longer > battery operated periods, depending on disk utilization patterns. Awesome. That would mean about 45 minutes more mobility with my laptop. :) Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Clear perl code is better than unclear awk code; but NOTHING comes close to unclear perl code" (taken from comp.lang.awk FAQ)