<br><br><div class="gmail_quote">On Thu, Apr 2, 2009 at 11:07 AM, Marc Randolph <span dir="ltr"><<a href="mailto:mrand@pobox.com">mrand@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I do care, but haven't seen a problem. Have you? If so, please<br>
elaborate! I'll take it for face value that it does some ugly SQL<br>
accessing during scheduling. What does that translate to in terms of<br>
system resources? Is it enough to swamp an IDE drive by itself, or do<br>
you only have problems on IDE when it is doing scheduling while<br>
simultaneously trying to record 4 shows at the same time? When you<br>
move to SATA, what does the utilization drop to?<br></blockquote></div><br><br>I have. My SATA drive, 500GB Seagate, worked fine for a while. But after about a year, I started getting breakups in the recordings. I checked the signal and tuner and discovered that it was fine. So I suspected I/O issues. Hacking the backend to remove the syncs and increasing the buffers helped a lot, but I still had some issues. So I grabbed an old 80GB drive I had floating around, dropped it in, and copied all the OS data over to it. A little work with grub and the BIOS, and I'm booting from the new drive. I kept the old drive in for recordings only. I have yet to see a breakup since. I am now convinced. Keeping the OS and database on a separate spindle is worth the bother. I'll probably do USB flash sticks in the future as they are cheap and big enough for what I need. <br>
<br>I didn't know how to log drive activity levels, but CPU levels are about 5-10% while recording. Makes sense as all the backend is doing is reading and writing data. It isn't doing any processing. I also tried disabling all jobs, no commflags or transcodes running. That also helped, but not enough. Now I can run jobs while the main backend is recording and it works fine. <br>
<br>The 80GB drive is a 5400RPM drive. I can tell it's slower during the boot, but once the system is running, it's not noticeable. I doubt it's the data rate really, it's the random I/Os that are killing it. The seek time + the transfer time is just enough to cause issues. Interestingly, even SSDs have had issues with random I/O and that's what most disk activity is on a modern system. <br>