Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!leonard.anu.edu.au!not-for-mail From: gpg109@leonard.anu.edu.au (Paul Gortmaker) Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux Date: 21 Feb 1996 09:25:16 +1100 Organization: Australian National University Lines: 46 Message-ID: <4gdhoc$pcf@leonard.anu.edu.au> References: <4er9hp$5ng@orb.direct.ca> <4f9skh$2og@dyson.iquest.net> <4fg8fe$j9i@pell.pell.chi.il.us> <311C5EB4.2F1CF0FB@freebsd.org> <4fjodg$o8k@venger.snds.com> <311DA774.167EB0E7@FreeBSD.org> NNTP-Posting-Host: 150.203.2.15 X-Newsreader: NN version 6.5.0 #12 (NOV) Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14074 comp.os.linux.development.system:17684 "Jordan K. Hubbard" <jkh@FreeBSD.org> writes: >An interesting test, the results of which would actually be quite >enlightening, would be to build two identical configurations and load >one with FreeBSD 2.1 and the other with, say, with RedHat 2.1 or Or just use one machine, and do the FreeBSD test, and then the Linux test, hitting the reset buttton after the same amount of elapsed time. No need to have two machines. >Slackware 3.0. Run a checksum scan across *every* file on each system >and store the results someplace where they can't be nuked. Now start an >application chosen for its disk-intensive nature, possibly with a few To be fair, the app should be identical in nature as well, such as untarring gcc or emacs source. A home-made app that creates lots of little files with prime numbers or something would be good to toss in as well. This still leaves a lot to be desired as a representation of the everyday use the filesystem sees. >recursive chowns/chmods of large file trees (not an uncommon thing to >find running on a typical UNIX system) sprinkled in. After a measured >amount of wall clock time, literally yank the plug out of the wall on >the test machine and bring it back up. Run your scan and see if any >files were lost, checking also to see how the application's own data >files were damaged, if at all (you obviously want to pick an application >that writes easily verifyable data). >Now do the same thing on the other box. How did it do? Even for this test to have any meaning, it would have to be repeated at least 10 times (for each Linux and FreeBSD - total of 20 runs!), hitting the reset button at various times, otherwise the statistics would still be meaningless. You would want to cat the raw disk device to tape to allow easy restoration for subsequent runs. This would guarantee the same initial file allocation for each run. You are looking at a full day of work to perform this test in a semi-meaningful manner. I'd expect that large memory machines would do worse in such a test, as they would be more likely to be sitting on large amounts of data that hasn't hit the platters when you hit the big red button. So you should then test a small and a large memory configuration as well. Oh, and then there is IDE vs. SCSI -- do things like tagged queueing make corruption from power failure more probable? The list is endless... Paul.