Date: Tue, 30 Jan 1996 15:24:29 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: toor@dyson.iquest.net (John S. Dyson) Cc: rajp@nando.net, hackers@FreeBSD.ORG Subject: Re: intested! Message-ID: <199601302224.PAA07645@phaeton.artisoft.com> In-Reply-To: <199601301002.KAA03213@dyson.iquest.net> from "John S. Dyson" at Jan 30, 96 10:02:46 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601302224.PAA07645>