Date: Mon, 11 Nov 1996 11:24:38 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: danj@3skel.com (Dan Janowski) Cc: bsdcur@shadows.aeon.net, jgreco@brasil.moneng.mei.com, freebsd-current@freebsd.org Subject: Re: ufs is too slow? Message-ID: <199611111724.LAA19552@brasil.moneng.mei.com> In-Reply-To: <199611111704.MAA12463@fnur.3skel.com> from "Dan Janowski" at Nov 11, 96 12:04:35 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I have seen that OpenBSD is doing something with lfs, but I > am not sure what. It would be worth while to get lfs running > for sure; if you ever wondered, a lot of that disk bandwith > goes to filesystem overhead. In the specific case of "lots of small articles being accessed all over the place", yes... in general I would have to disagree :-) With the "-noatime" hack, you gain some of that bandwidth back by not having to support all the crummy metadata updates that you probably didn't care too much about anyways. > I once exchanged some e-mail with someone at BSDI and with > Margo Seltzer, who was a principle for lfs. The apparent > primary reason why lfs does not run here is that lfs does some > wierd stuff with the ATT buffer code that is missing in > 4.4-lite. I was not able to get a synopsis of what or how to > get around it, but it didn't sound like lfs was broken, it's > just missing some wheels. > > Maybe we can all talk about it a little and figure out > how hard it would be to get going. If we were running > a kick-ass big/fast file system, FreeBSD would capture > some more of the Int(er|tra)+Net market. In addition > to which, the infamous 'make world' time would surely > benefit. While I agree with this analysis, I unfortunately lack the skills and internals knowledge to even contemplate doing something like this... otherwise I would be off writing "newsfs" in a corner somewhere. ... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611111724.LAA19552>