Dear Freddie, >> You may want to play around with gshed, the GEOM Scheduler. >> >> Matt Dillon did a bunch of tests comparing FreeBSD+UFS to >> DragonflyBSD+HAMMER and found that FreeBSD starves read threads in >> order to satisfy write threads (or the other way around?). But, >> adding gsched into the mix helped things immensely, allowing mixed >> reads/writes to better shares disk I/O resources. >> >> I'll see if I can dig up a link to his testing e-mail messages. > > Here's the post, part of a thread on benchmarking RAID controllers: > > http://leaf.dragonflybsd.org/mailarchive/kernel/2011-07/msg00034.html
*cloink* /me goes to pick my jam off of the floor. I can insert a I/O scheduler in full flight? Ok. I need to adjust my mental image of the world a bit. I just played with the examples on a test machine and the effect is quite visible. I ran a CVS checkout of the ports collection concurrent with dd writing a massive file. Insert scheduler -> CVS update is faster; destroy scheduler -> CVS update crawls. This is so easy it's almost scary. The behaviour that Matt describes is what I thought I was seeing too: write a *lot* and it becomes hard to read from the disk. In my system, writing data is largely asynchronous and can lag the actual arrival of data by as much as a few minutes. Reads are always synchronous to a user request and need to be served asap. Some writes are database writes and they should be services quickly too. This is definitively something I need to look into. Thank you for the reference. -- Kees Jan http://java-monitor.com/ [email protected] +31651838192 Change is good. Granted, it is good in retrospect, but change is good. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
