<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1" />
<title>Re: [mythtv-users] Opinion on a P4 Backend // HDD Throughput</title>
</head>
<body dir="ltr">
<p>Thanks to all for your feedback - seems I am okay with my setup and will give it a go. <br /></p><p>Next is trying to price out a few FE's - for SD playback and also, when it is time, to buy some more robust FEs for later HD playback.<br /></p>On the splitting of drives - I fully understand where you are all going with that. I am developer and use Progress (transactional database/language) [now called Open Edge]. All transactions are written to the BI (before image) which then writes to the DB and then the BI records are committed. Works great if the system is shutdown or crashes since any partial transactions uncommitted will be backed out automatically upon restart; client disconnect etc.<br /><br />Where I am going is that in a perfect world we would have a small 10GB HDD for the O/S; 5GB for logging; 10GB for the "BI" file and then multiple drives for each "area" (part of the total DB). Sadly the direction is bigger and bigger making such methods not cost effective. SSD's (solid state) have issues with the number of times being written to the same spot - logs would definitely be an issue. I have read there are improvements to spread the writes across different spots but that only works so much.<br /><br />I was considering an SSD for the FE's - to cut down on heat and noise - but even assuming there is little done by Myth with FEs (writing out) there still are logs from the O/S. CD is a thought (hate hate hate optics) but the concern is that it is a crap shoot whether you get a drive that makes noise (like an airplane) when accessed. HDDs - well back to the point of this email - I would love a small HDD that is quiet and cool - even a 4800-5400 RPM would be sufficient for booting up. Haven't looked into that - any thoughts? Cheap too - seeing as they don't have to be more than say 5GB (something along the lines of the HDDs used by the iPods perhaps). But then the burn is the size - small = more money. I guess I can dream - but will still research that.<br /><br />Q-Assuming one does a LOT of recording (not sure if there are stats somewhere on this) - about how much disk space should allocated to the myth database? I figure a 120GB - and divide it into two - and use the non-OS/log side for archiving. Then have a bunch of other HDDs for recording. Are we talking up to 2GB; 5GB or 10GB for the average DB? I assume there is some pruning/purging/compacting/reindexing routines.<br /><br />Cheers all!<br />jeff<br /><pre>
----- Original message -----
From: "Kevin Kuphal" <kkuphal@gmail.com>
To: "Discussion about mythtv" <mythtv-users@mythtv.org>
Date: Wed, 5 Mar 2008 16:32:51 -0600
Subject: Re: [mythtv-users] Opinion on a P4 Backend // HDD Throughput
</pre>
<div class="gmail_quote">On Wed, Mar 5, 2008 at 4:25 PM, Gareth Glaccum <<a href="mailto:gareth.glaccum@btopenworld.com">gareth.glaccum@btopenworld.com</a>> wrote:<br />
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br />----- Original Message -----<br />From: <<a href="mailto:greg@nodecam.com">greg@nodecam.com</a>><br />>On my system (one firewire tuner, one PVR 250) I could cause problems by<br />>recording HD, playing back the same HD stream on a delay and recording SD<br />
>at the same time. As soon as I put in a new disk and separated recordings<br />>from database/logging, the problems went away.<br /><br /></div>That doesn't really make sense. Logging and database access is a minimum in<br />
the situation you desribed (EIT scanning is about it I think), just moving<br />the logs and database should have made little difference really.<br />Ok, if you are running more than just myth, a lot of logging and seperate<br />
database accesses in the background then this would make a difference.</blockquote>
<div> </div>
<div>Myth writes *alot* of data for the seektables when recording. The commflag process reads that as well as your playback so when you start to get a handful of recordings, especially HD where the bitrates are higher, the database gets hit pretty hard.</div>
<div> </div>
<div>Kevin</div></div>
</body>
</html>