Date: Thu, 24 May 2001 23:36:33 -0400 From: Shannon Hendrix <shannon@widomaker.com> To: Terry Lambert <tlambert@primenet.com> Cc: hackers@freebsd.org Subject: Re: technical comparison Message-ID: <20010524233631.B13575@widomaker.com> In-Reply-To: <200105242235.PAA13693@usr02.primenet.com>; from tlambert@primenet.com on Thu, May 24, 2001 at 10:34:26PM %2B0000 References: <200105242235.PAA13693@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 24, 2001 at 10:34:26PM +0000, Terry Lambert wrote: > ] > 1. I don't think I've ever seen a Linux distro which has write > ] > caching enabled by default. Hell, DMA33 isn't even enabled > ] > by default ;) > ] > ] You are talking about controlling the IDE drive cache. > ] > ] The issue here is write cache in the filesystem code. > > No. The issue here is the write cache on the drive. > FreeBSD with soft updates will operate within 4% of the top memory > bandwidth; see the Ganger/Patt paper on the technology. I have a file, CSE-TR-254-95.ps, that I think is probably the paper you are talking about. The title is "Soft Updates: A Solution to the Metadata Update Problem in File Systems". The link on Ganger's page was dead, but I'm sure this is the one you mean. Nowhere do they support the idea that soft udpates can approach a system's memory bandwidth. What they did say was that in _one_ case, creating and then immediately deleting a directory entry, you are operating at processor/memory speeds. They said soft updates in that case were 6 times faster than the conventional system. That's not even close to the memory bandwidth of the 486 system they were using, so they had to mean the filesystem code in that test was able to run without waiting on I/O. In the more general cases, their findings were "more than a factor of two" compared to synchronous write ufs. I _wish_ my workstation was able to write metadata at nearly 1GB/s all the time... :) -- "Star Wars Moral Number 17: Teddy bears are dangerous in herds." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010524233631.B13575>