Re: web write-up
In [EMAIL PROTECTED], Shaun Dwyer [EMAIL PROTECTED] typed: Mike Meyer wrote: [SWAG follows] I Disagree.. it will make a difference. If you partion /var near the beginning of the disk (the fastest part - outer tracks) it will force all the stuff in /var (being logs and stuff) to live at the faster area of the disk. That could well be - after all, this is all just idle speculation. But then you're seeking all over the disk looking for the data that's being used by the processes that are writing to the log. Which is worse? im sure there are several other reasons to make seperate partitions. Off the top of my head: stop file systems from filling up if you have a process dumping large ammounts of data some where Yup, but we're talking about two stable file systems - / and /usr - and the log file system /var. Letting / and /usr fill up is nearly harmless - you can lose the password file on / if someone tries to change it - so combining those three so that /var has the extra space means you are less likely to run out of space on it, and at minimal risk. If you have a system where passwords are changing frequently and there's a lot of activity on /var, the risk might be higher. if one file system is corrupted, you dont lose _everything_. Discounting the potential pefformance benefits, these two reasons alone should be enough to create seperate file systems. When was the last time you saw a file system so corrupted it couldn't be recovered? Modern file systems - at least on the Eunices I work with - are sufficiently robust that the risk involved isn't worth the extra headaches created by having extra partitions. Generally, the valid reasons for splitting file systems are administrative or physical. Physical because you've got them on different spindles, and administrative because you're treating them differently: different backups, different mount permissions, different upgrade paths, different exports, different owners, or something along those lines. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: web write-up
Sean Ellis wrote: Hello freebsd-questions, I wonder if anyone has any comment on this web article. The results of the benchmarking seem to portray FreeBSD in a less than favourable light. http://www.samag.com/documents/s=1148/sam0107a/0107a.htm It looks like garbage to me. He doesn't give enough information to reproduce his results, though I strongly suspect the FreeBSD box has softupdates disabled, and is therefore going to be slower. His writeup isn't even very good. On the initial page he claims they tested with FreeBSD, but on sidebar #2 he claims they used OpenBSD. -- Bill Moran Potential Technologies http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: web write-up
On Thu, 2003-01-09 at 03:53, Sean Ellis wrote: Hello freebsd-questions, I wonder if anyone has any comment on this web article. The results of the benchmarking seem to portray FreeBSD in a less than favourable light. http://www.samag.com/documents/s=1148/sam0107a/0107a.htm Please CC any replies as I am not currently subscribed. Linux comes out the fastest because they do fun things like including support for http in the kernel. I have heard of a lot of problems with postfix on Linux because the filesystem doesn't journal properly so in the event of a crash all your mail is lost (postfix was told it was delivered, etc). Recent research into NFS I have done also suggests that Linux is much slower than FreeBSD due to the nature of network buffering. I would say that the benchmarks were performed on stock installs without optimizations (such as recompiling the kernel to take advantage of a P3 or better). Given the opportunity to tweak each setup, my guess is Linux and FreeBSD would be on top, with Windows ranking last (because it's not open source, you have less control - what you get is what Microsoft gave you). I'm not advocating any operating system above any other. I think people should determine what they want to do with their system, find out what platforms are capable of handling it, and perform their own benchmarks for their particular application. If only the authors of such articles, who really should know better, did the same thing. -- The information contained in this email is confidential. If you are not the intended recipient, you may not disclose or use the information in this email in any way. Dark Blue Sea does not guarantee the integrity of any emails or attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Dark Blue Sea. Dark Blue Sea does not warrant that any attachments are free from viruses or other defects. You assume all liability for any loss, damage or other consequences which may arise from opening or using the attachments. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
RE: web write-up
Personally - I dont care what some lamer writer said - what I CARE about is that I SLEEP at nite since switching to fbsd.. the fbsd programmers saved me from tossin myself off a roof! Did you switch from Linux or Windoze to FBSD? Kory To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: web write-up
Sean Ellis wrote: Hello freebsd-questions, I wonder if anyone has any comment on this web article. The results of the benchmarking seem to portray FreeBSD in a less than favourable light. http://www.samag.com/documents/s=1148/sam0107a/0107a.htm Please CC any replies as I am not currently subscribed. I would tend to think that these people did bugger all in terms of performance tuning the FreeBSD box. It wouldnt surprise me if they didn't turn on soft updates for one. Other thing that is quite likely is they probably didn't make seperate slices for /, /var and /usr. I would guess that they did some (probably limited) tuning to the Linux box they were testing with. If you look at the 'Sidebar 2' page, they state a few OSs they use internally, Linux being one. I suspect that they might be knowlegeable about Linux, Solaris and Windoze and performance tuning each (look at what they use them for). The only BSD they have is OpenBSD for their firewall(s). Not much tuning needed there to get good network performance. Same goes with FreeBSD if all you are doing is using it for a firewall. Based on this I'd say they have little to no experiance tuning FreeBSD/*BSD for performance. That being said, anyone that claims FreeBSD's performance isn't that great is probably full of shit. Check their background, I bet they don't specialise in any sort of BSD, or have used it much at all :) --Shaun To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
RE: web write-up
Personally - I dont care what some lamer writer said - what I CARE about is that I SLEEP at nite since switching to fbsd.. the fbsd programmers saved me from tossin myself off a roof! Did you switch from Linux or Windoze to FBSD? linux and sco To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: web write-up
On Wed, 08 Jan 2003 12:19:20 -0500 Bill Moran [EMAIL PROTECTED] wrote: Sean Ellis wrote: Hello freebsd-questions, I wonder if anyone has any comment on this web article. The results of the benchmarking seem to portray FreeBSD in a less than favourable light. http://www.samag.com/documents/s=1148/sam0107a/0107a.htm It looks like garbage to me. He doesn't give enough information to reproduce his results, though I strongly suspect the FreeBSD box has softupdates disabled, and is therefore going to be slower. His writeup isn't even very good. On the initial page he claims they tested with FreeBSD, but on sidebar #2 he claims they used OpenBSD. the only tuning they did (kernel tweaks for high performance lol) was upping kern.maxfiles and kern.maxfilesperproc... all one can argue this shows is that out of the box freebsd 4.2 isn't configured for optimal performance on these tests... `Anti` To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: web write-up
On Thursday 09 January 2003 12:09, Shaun Dwyer wrote: is they probably didn't make seperate slices for /, /var and /usr. What difference does it make as to wether these partions are seperate. I realise if you have more than one ide drive then having them on seperate drives is alot better. On single drive machines I usually make only one partion, what reasons are there to slice it? - jacob Jacob RhodenPhone: +61 3 8344 6102 ITS DivisionEmail: [EMAIL PROTECTED] Melbourne University Mobile: +61 403 788 386 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: web write-up
JacobRhoden wrote: On Thursday 09 January 2003 12:09, Shaun Dwyer wrote: is they probably didn't make seperate slices for /, /var and /usr. What difference does it make as to wether these partions are seperate. I realise if you have more than one ide drive then having them on seperate drives is alot better. On single drive machines I usually make only one partion, what reasons are there to slice it? It makes a lot of difference. I don't remember the exact numbers, but the inside of the drive spindle transfers data noticably faster than the outside. Therefore, putting busy partitions (such as /var and /tmp) at the beginning of the drive can improve performance a good bit. Additionally (if you really want to crank up the throughput) you can format and mount partitions with options that better benefit their purpose (such as mounting noatime on a /tmp partition). So, proper partitioning CAN make a big difference in performance. Especially since the hard drive can _easily_ become the performance bottleneck on a server. -- Bill Moran Potential Technologies http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: web write-up
In [EMAIL PROTECTED], JacobRhoden [EMAIL PROTECTED] typed: On Thursday 09 January 2003 12:09, Shaun Dwyer wrote: is they probably didn't make seperate slices for /, /var and /usr. What difference does it make as to wether these partions are seperate. I realise if you have more than one ide drive then having them on seperate drives is alot better. On single drive machines I usually make only one partion, what reasons are there to slice it? [SWAG follows] From a performance standpoint, putting them on separate slices on the same disk is probably a loss. It forces the blocks in those file systems to live spread out across the disk, meaning the time optimizations are constrained to those blocks, whereas if you put them all in one file system then the disk scheduler can play with the entire disk. That said *THIS DOESN'T MAKE ANY PRACTICAL DIFFERENCE*. The scheduler already slices partitions up into cylinder groups and tries to make files live on specific cylinder groups. Having different file systems just means lets it pick from a smaller set of cylinder groups. If your disk is so heavily loaded that this makes a difference, you really want multiple spindles. There are administrative reasons to split them up. For instance, the backup for /usr is the FreeBSD CDROM set. / and /var I create backups for, so /usr gets it's own file system, and /var lives on /. On a second system, / and /usr are mounted read-only - well, they should be - but /var has the web site on it, which gets updated at regular intervals. So /var gets it's own file system, and /usr lives on /. On my test system, which gets config files stored in perforce, I just make everything one big file system. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: web write-up
Mike Meyer wrote: In [EMAIL PROTECTED], JacobRhoden [EMAIL PROTECTED] typed: On Thursday 09 January 2003 12:09, Shaun Dwyer wrote: is they probably didn't make seperate slices for /, /var and /usr. What difference does it make as to wether these partions are seperate. I realise if you have more than one ide drive then having them on seperate drives is alot better. On single drive machines I usually make only one partion, what reasons are there to slice it? [SWAG follows] From a performance standpoint, putting them on separate slices on the same disk is probably a loss. It forces the blocks in those file systems to live spread out across the disk, meaning the time optimizations are constrained to those blocks, whereas if you put them all in one file system then the disk scheduler can play with the entire disk. That said *THIS DOESN'T MAKE ANY PRACTICAL DIFFERENCE*. The scheduler already slices partitions up into cylinder groups and tries to make files live on specific cylinder groups. Having different file systems just means lets it pick from a smaller set of cylinder groups. If your disk is so heavily loaded that this makes a difference, you really want multiple spindles. There are administrative reasons to split them up. For instance, the backup for /usr is the FreeBSD CDROM set. / and /var I create backups for, so /usr gets it's own file system, and /var lives on /. On a second system, / and /usr are mounted read-only - well, they should be - but /var has the web site on it, which gets updated at regular intervals. So /var gets it's own file system, and /usr lives on /. On my test system, which gets config files stored in perforce, I just make everything one big file system. mike I Disagree.. it will make a difference. If you partion /var near the beginning of the disk (the fastest part - outer tracks) it will force all the stuff in /var (being logs and stuff) to live at the faster area of the disk. If your server is being hit really hard, im sure you dont want it seeking all over the disk to write to logs. This could potentially add up to quite a performance hit. While an attempt is made to ensure that a file exists in the same cyl group, there is no garantee. if your logs grow to be quite large. im sure there are several other reasons to make seperate partitions. Off the top of my head: stop file systems from filling up if you have a process dumping large ammounts of data some where, if one file system is corrupted, you dont lose _everything_. Discounting the potential pefformance benefits, these two reasons alone should be enough to create seperate file systems. --Shaun To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
