From owner-freebsd-hackers Tue Jan 30 14:28:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA11266 for hackers-outgoing; Tue, 30 Jan 1996 14:28:11 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA11167 for ; Tue, 30 Jan 1996 14:28:05 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA07645; Tue, 30 Jan 1996 15:24:30 -0700 From: Terry Lambert Message-Id: <199601302224.PAA07645@phaeton.artisoft.com> Subject: Re: intested! To: toor@dyson.iquest.net (John S. Dyson) Date: Tue, 30 Jan 1996 15:24:29 -0700 (MST) Cc: rajp@nando.net, hackers@FreeBSD.ORG In-Reply-To: <199601301002.KAA03213@dyson.iquest.net> from "John S. Dyson" at Jan 30, 96 10:02:46 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > FreeBSD does have one major "problem" that I worry about alot, and that > is the disk metadata thing. We have been improving the situation, and > hopefully soon will make a major performance impact. I can't agree with this one, and this is probably why you quoted the word 'problem'. In case it isn't: I think the correct soloution for a UFS layout file system is delayed ordered writes, which make the same guarantess without the overhead. The VIVAFS does this, and it is a win, even without the other stuff they do that *does* impact on disk layout. UnixWare 2.x does this (and had a patent pending, which should be denied on the basis of prior art) and got a 160% performance increase from UnixWare 1.x to UnixWare 2.x, even after adding SMP synchronization to the kernel. The actual method of implementation is irrelevant: ordered queue insertion and kernel threading are both valid mechanisms. For a non-UFS FS, the correct soloution is transaction tracking, either through journalling (like NTFS and IBM JFS), or logging (like Sprite or LFS). All of these soloutions end up with a performance boost without breaking the consistency guarantees inherent in operation ordering. All of them are a lot more than "five minute fixes". They should not be discounted because they can't be implemented in a day of hard hacking. The *only* valid reason for breaking consistency guarantees is speed of administrative operations and/or temp data storage (data that is to be destroyed on a system reinitialization in any case). To paraphrase a wise friend of mine: "I can make it as fast as you want it to be if it doesn't have to work". Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.