From owner-freebsd-stable@FreeBSD.ORG Tue Apr 15 16:27:46 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 3B57637B401; Tue, 15 Apr 2003 16:27:46 -0700 (PDT) Received: from mail.tel.fer.hr (zg06-140.dialin.iskon.hr [213.191.148.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B29643F75; Tue, 15 Apr 2003 16:27:44 -0700 (PDT) (envelope-from zec@tel.fer.hr) Received: from tel.fer.hr ([192.168.202.105]) by mail.tel.fer.hr (8.12.6/8.12.6) with ESMTP id h3FNPpxK000691; Wed, 16 Apr 2003 01:25:55 +0200 (CEST) (envelope-from zec@tel.fer.hr) Message-ID: <3E9C9566.8603E312@tel.fer.hr> Date: Wed, 16 Apr 2003 01:27:34 +0200 From: Marko Zec X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Dillon References: <3E976EBD.C3E66EF8@tel.fer.hr> <20030414101935.GB18110@HAL9000.homeunix.com> <20030415160925.U86854@duey.wolves.k12.mo.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Tue, 15 Apr 2003 23:27:46 -0000 Chris Dillon wrote: > On Tue, 15 Apr 2003, Marko Zec wrote: > > > 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. > > Sorry to butt in on this thread... :-) It just occurred to me that > the ability to delay all writes given an arbitrary time period would > be good for more than just laptops. It would be great for > non-volatile flash filesystems which have a limited write life. The > only thing you would have to change for that case is make the "flush > on read" optional, since the purpose would be to minimize writes, not > minimize disk spin-ups which don't exist on flash parts. This would > only be advantageous if delaying the writes will actually cause fewer > writes to be made to the flash part than would have been made without > the delay, i.e. via normal soft-updates optimizations (a file created > and removed within the delay period never gets written, or delaying > atime updates of oft-read files), which I'm guessing would be the case > most of the time. To achieve such a functionality, simply remove or comment out the stratcalls++ line in /sys/dev/ata/ata-disk.c. A cleaner method would of course be adding another tunable knob, which would also be a trivial thing to... Cheers, Marko > For example, on a small flash-based firewall I currently use at home, > I would use a delay time of 60 minutes or more. That would correspond > to how I currently handle saving the important dynamic information > kept on a memory filesystem, such as DHCP leases, which is every 60 > minutes mount a small filesystem read-write on the flash part, tar up > the dynamic data, and then umount the filesystem. I then have to > un-tar that data onto the memory filesystem during boot. Being able > to keep all of that information directly on a read-write filesystem on > the flash part but delay writes for a relatively long period of time > would alleviate all of that. > > If the "clean" bit is set on the FS during that long delay that would > be even slicker (does it do that already?), since if the filesystem is > consistent thanks to softupdates it shouldn't need to be fsck'd at all > on boot. > > -- > Chris Dillon - cdillon(at)wolves.k12.mo.us > FreeBSD: The fastest and most stable server OS on the planet > - Available for IA32 (Intel x86) and Alpha architectures > - IA64, PowerPC, UltraSPARC, ARM, and S/390 under development > - http://www.freebsd.org > > No trees were harmed in the composition of this message, although some > electrons were mildly inconvenienced.