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>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104052352.f35NqOP02879>