Date: Fri, 06 Apr 2001 00:52:24 +0100 From: Brian Somers <brian@Awfulhak.org> To: freebsd-arch@FreeBSD.org Cc: mckusick@mckusick.com, Brian Somers <brian@Awfulhak.org> Subject: A soft-updates optimisation ? Message-ID: <200104052352.f35NqOP02879@hak.lan.Awfulhak.org>
index | next in thread | raw e-mail
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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104052352.f35NqOP02879>