> > My question is why is FreeBSD's disk i/o performance so bad? > > As I mentioned... this was discussed actively in slashdot. You will find > there many good comments on this.
All I saw in slashdot was a ffs vs ext comment. I don't believe the problems I'm seeing are filesystem related. > > Not just in the benchmarks with debugging on, but in real world usage > > where it actually matters. > > Are you saying this from actual experience or from reading other people's > comments? Here is a specific demo of one disk i/o problem I'm seeing. Should be easy to reproduce? http://lists.freebsd.org/pipermail/freebsd-performance/2008-July/003533.html This was over a year ago, so add 7.1 to the list of versions with the problem. I believe that the swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1148109, size: 4096 messages I'm getting are the same problem. A user process is hogging the bottleneck (disk buffer cache?) and the swapper/pager is getting starved. I frequently see problems where disk i/o on one disk starves a process that needs disk i/o on a different disk on a different controller, which is why I suspect the disk buffer cache as the bottleneck. > If it is from actual experience and XYZ version of Linux does a > particular job better then I don't see why you should not consider using > what works best. I was stuck running Linux on one machine for awhile and it scrambled my data. No thank you. Data integrity is essential. Thankfully I have been penguin free for awhile now. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[email protected]"
