From owner-freebsd-fs@FreeBSD.ORG Sat Apr 12 09:37:22 2003 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2AF737B401; Sat, 12 Apr 2003 09:37:22 -0700 (PDT) Received: from tel.fer.hr (zg05-232.dialin.iskon.hr [213.191.138.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1541D43FBD; Sat, 12 Apr 2003 09:37:21 -0700 (PDT) (envelope-from zec@tel.fer.hr) Received: from tel.fer.hr ([192.168.202.105]) by tel.fer.hr (8.12.6/8.12.6) with ESMTP id h3CGZXaA000355; Sat, 12 Apr 2003 18:35:36 +0200 (CEST) (envelope-from zec@tel.fer.hr) Message-ID: <3E9840B8.F00E018F@tel.fer.hr> Date: Sat, 12 Apr 2003 18:37:12 +0200 From: Marko Zec X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-stable@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG References: <200304121438.h3CEct41030991@lurza.secnetix.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: PATCH: Forcible delaying of UFS (soft)updates X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2003 16:37:23 -0000 Oliver Fromme wrote: > 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. That would certainly be cool, however I have no clue if and how such model could be implemented. But what I can safely assume is that it wouldn't be nearly as simple as the original patch. > > - 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). I agree that additional tunable for controlling fsync() behavior couldn't hurt, however as explained in previous note I see the fsync() as the most common initiator of disk spinnups, so a method for suppressing it must be made available, otherwise the whole patch wouldn't make much sense... > > - 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.) As far as I understand how softupdates work, the algorithm ensures the data is _always_ written to disk before the metadata, so that shouldn't be a problem. Cheers, Marko