<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 30, 2015 at 3:15 PM, M. Edward (Ed) Borasky <span dir="ltr"><<a href="mailto:znmeb@znmeb.net" target="_blank">znmeb@znmeb.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Mar 30, 2015 at 2:43 PM, drago01 <<a href="mailto:drago01@gmail.com">drago01@gmail.com</a>> wrote:<br>
><br>
> <a href="https://lwn.net/Articles/572911/" target="_blank">https://lwn.net/Articles/572911/</a><br>
> <a href="https://lwn.net/Articles/467328/" target="_blank">https://lwn.net/Articles/467328/</a><br></blockquote><div><br></div><div>Thanks for the info. That's very helpful, but it looks like that discussion didn't come to any sort of resolution. Do you know if it's being picked up anywhere else?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yeah, I vaguely remember that discussion. I went down this rabbit hole<br>
in mid-2008, wrote a couple of papers and moved on with my life.<br>
There's no software solution - get faster hardware and more RAM and<br>
don't design I/O-bound systems.</blockquote><div><br></div><div>That works for a lot of problems, but some are I/O-bound by definition. Databases are a prime example of a task of that (and the one that started me looking into this). For any non-trivial application, you'll never be able to throw enough CPU/RAM at the problem to make the disk not matter when the system in under heavy use.<br></div></div></div></div>