Date: Sun, 8 Mar 1998 01:00:17 +0100 (CET) From: Mikael Karpberg <karpen@ocean.campus.luth.se> To: toor@dyson.iquest.net (John S. Dyson) Cc: current@FreeBSD.ORG Subject: Re: Okay, -current should be conditionally safe to use Message-ID: <199803080000.BAA03875@ocean.campus.luth.se> In-Reply-To: <199803072256.RAA02792@dyson.iquest.net> from "John S. Dyson" at "Mar 7, 98 05:56:58 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
According to John S. Dyson: > I have committed all of my pending NFS, VFS and VM fixes. The regression > tests have been run, and the system has run nicely with my normal load and > an artifically high load. Well, not really feedback, I'm affraid. However, when I read your commit messages, I thought of something. At out computer society we have a Sun with a presto card (I think... Battery backed write cache for the scsi chain, or something). That made a big difference when handling NFS writes. Even with a pretty nifty FreeBSD machine it was hard to keep up with the write speeds we saw on the Sun, IIRC. Now, ofcourse, the Sun was cheating and using "UPSed cache", so it could write to memory and return that everything went well even before the first byte hit the disk. So, we have to ask ourselfs how to "cheat right back"? Which leads to my question... Would tuning the NFS exported disk SoftUpdates do a significant difference? For the moment I don't think we're ready to use the SoftUpdates code, since we're using the machine for more then just play, but it might be an interesting thing to try once it's more robust. /Mikael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803080000.BAA03875>