Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 5 Apr 2001 19:55:48 -0400 (EDT)
From:      Joseph Mallett <jmallett@newgold.net>
To:        Brian Somers <brian@Awfulhak.org>
Cc:        freebsd-arch@FreeBSD.ORG, mckusick@mckusick.com
Subject:   Re: A soft-updates optimisation ?
Message-ID:  <Pine.BSO.4.21.0104051954450.26913-100000@aphex.newgold.net>
In-Reply-To: <200104052352.f35NqOP02879@hak.lan.Awfulhak.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <brian@Awfulhak.org>                        <brian@[uk.]FreeBSD.org>
>       <http://www.Awfulhak.org>;                   <brian@[uk.]OpenBSD.org>
> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSO.4.21.0104051954450.26913-100000>