From owner-freebsd-arch Thu Apr 5 16:56:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aphex.newgold.net (durham0-128.dsl.gtei.net [4.3.0.128]) by hub.freebsd.org (Postfix) with ESMTP id 7715C37B443 for ; Thu, 5 Apr 2001 16:56:45 -0700 (PDT) (envelope-from jmallett@newgold.net) Received: from localhost (jmallett@localhost) by aphex.newgold.net (8.10.1/8.10.1) with ESMTP id f35NtmN24653; Thu, 5 Apr 2001 19:55:48 -0400 (EDT) Date: Thu, 5 Apr 2001 19:55:48 -0400 (EDT) From: Joseph Mallett To: Brian Somers Cc: freebsd-arch@FreeBSD.ORG, mckusick@mckusick.com Subject: Re: A soft-updates optimisation ? In-Reply-To: <200104052352.f35NqOP02879@hak.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You mean like, if the data was stored in a "seperate" (as far as the FS _looks_ and _acts_) location and then put in place of the original once the update could be completed? If that's what you mean (or jut holding it in ram) then wouldn't there be overhead problems? Or am I totally missing the point? /joseph -- Joseph Mallett Security Specialist +1 919 349 2976 www.newgold.net josephm@ohsmeg.com jmallett@newgold.net xMach: The proactively unbloated microkernel 4.4BSD-like operating system. www.xMach.org On Fri, 6 Apr 2001, Brian Somers wrote: > Hi, > > I was thinking about soft-updates a bit today and an irritating > problem that I (and I assume others) am seeing. > > If I'm doing a build of some sort (probably make world) and I lose > my machine for whatever reason, the machine almost always comes back > up with either a binary or object of zero length. > > I guess the reason is because the write queue looks something like > this (from a simplistic point of view): > > o Create inode with 0 size > o Allocate bitmaps > o Do a [clustered] write > o Update the inode size and times > o Repeat previous 3 steps lots of times > > and the optimiser must be optimising-out all of the inode updates > except for the last one. > > *Assuming* that this is what's happening (to be honest, I haven't > looked at the code), wouldn't it be infinitely better if the first > step (inode creation) could be delayed 'till the end and merged with > that final update ? > > For build scenarios, this would change the FS behaviour so that the > file is either all there or not there. A ``make -DNOCLEAN > buildworld'' would pick up where the previous one left off. > > Comments ? > -- > Brian > > Don't _EVER_ lose your sense of humour ! > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message