Return to BSD News archive
Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!chi-news.cic.net!newsxfer2.itd.umich.edu!gatech!news.sprintlink.net!news1!not-for-mail From: root@dyson.iquest.net (John S. Dyson) Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux X-Nntp-Posting-Host: dyson.iquest.net Message-ID: <4g4up4$6r2@dyson.iquest.net> Sender: news@iquest.net (News Admin) Organization: John S. Dyson's home machine References: <4er9hp$5ng@orb.direct.ca> <4g0sam$r6p@agate.berkeley.edu> <4g33tp$esr@park.uvsc.edu> <4g57cj$gc3@pell.pell.chi.il.us> Date: Sat, 17 Feb 1996 16:12:20 GMT Lines: 68 Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14577 comp.os.linux.development.system:18293 In article <4g57cj$gc3@pell.pell.chi.il.us>, Orc <orc@pell.chi.il.us> wrote: > > Yes, and this is a known problem with Linux. Will it stay that way? >Dunno; certainly people are looking at the buffer caching and changes >may happen to it. But from my experience of relative performance (Linux >1.2 vs FreeBSD 2.0), this behavior is hidden by the default behavior of >the ext2 filesystem, which shows that it's hard to point at one behavior >of a system and say whether or not it's speeding things up or slowing it >down in regards to another system. > From my view, I see three major reasons for comparing systems based upon benchmarks (there are probably more, but these are the ones that I think of): 1) To find deficiencies in one implementation or another to find problems to fix. 2) To use for marketing reasons. 3) To warn of potential performance problems so that users can be appraised of performance related issues when using a system. As a developer of FreeBSD, I tend to look at the first(1) one above. I use performance regression tests (and a small subset of those include lmbench, bonnie, and iozone). If Linux or FreeBSD has significant performance anolmolies, I review them carefully to make sure that there isn't a bug in FreeBSD. I cannot dispute that given people *sometimes* really need high metadata performance, FreeBSD did not afford the capability, and that was a disadvantage. Those that do massive filesystem restores on FreeBSD can attest to that. I added the async option to mitigate the problem for system admins, etc. In fact, I run my news partition async on FreeBSD-current also. There is a risk, and I am willing to take it. The question is whether or not to subject the users to a behavior that they previously did not expect. Linux has an advantage from that perspective because the filesystem has historically been async. FreeBSD has been historically sync with closer to provable fsck behavior. Making the decision as to which behavior we should support is being left in the hands of the user base, with the default on FreeBSD to using the historical FreeBSD method. This, of course, makes certain benchmarks look worse, but I don't think that it is necessarily a good thing to optimize just for benchmarks. In specific cases, we are using async metadata. I have heard that the install team is now using async mounts for the install package, for example. For the general case of "fixing" the metadata update performance, we intend to go in the direction of implementing conservative behavior, while improving performance. However, FreeBSD will continue to support async metadata when the highest performance is needed at the slight risk of filesystem damage. It isn't a bug that FreeBSD does sync metadata updates, but there might be some performance anomolies associated with our implementation. Regarding item three(3) above, if metadata perf is more critical than the slight risk of metadata damage, use the async option on the mount. This option will be available on the next release, and has been in current for a long time. I resisted adding the async option, but it has been proven to be advantageous. Likewise, it isn't a bug that Linux does async metadata updates, because the user base expects the behavior. In fact, it would be likely that if Linux suddenly made the default mount option sync, the user base would be unhappy with the drop in performance. Same problem with unfulfilled expectations that FreeBSD users would have. John Dyson dyson@freebsd.org