No subject
Sat Jun 21 03:26:05 UTC 2008
recording going at the time of the expiration. In the case of a single
recording on what we can assume are all full partitions (each one has about
the same amount of free space indicating to me that they are all at
capacity), then Myth, based on the Wiki quote, will use the local disk first
for the next recording (remember, Storage Groups only dictate where a
recording will be stored, not what will be expired). As a result of local
disk being chosen, local programs are being expired.
Seems simple enough to me and exactly as described. I would guess he could
test this by running multiple recordings and seeing that they probably get
spread to non-local disk after the first or second recording and the
resulting expirations take place. I think the suggestion of changing the
local weighting is the best and documented solution.
Kevin
------=_Part_26508_27740542.1219757825841
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<div dir="ltr"><div class="gmail_quote">On Tue, Aug 26, 2008 at 4:50 AM, Yeechang Lee <span dir="ltr"><<a href="mailto:ylee at pobox.com">ylee at pobox.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="Ih2E3d">Michael T. Dean <<a href="mailto:mtdean at thirdcontact.com">mtdean at thirdcontact.com</a>> says:<br>> > If you read my original post, I mention that there are hundreds of<br>> > items on the auto-expire list that precede the recordings in<br>
> > question. My auto expire is set to only consider age. My issue<br>> > is that they are not being expired in this order.<br>><br>> They sure are. You're forgetting about the fact that the "hundreds"<br>
> of items on the auto-expire list that precede the recordings in<br>> question are on other filesystems (where deleting them would be a<br>> waste, as it would mean hundreds of recordings must be deleted<br>> before a deletion actually makes space available for the new<br>
> recording).<br><br></div>The last sentence is a non sequitur.<br><br>I'm firmly on Jonny B and Enigma's side. Michael, you and Kevin are<br>both flat-out wrong on this issue. I'm very surprised that Kevin would<br>
miss this, as he is normally very on-target.</blockquote>
<div> </div>
<div>Thank you, but I was certainly starting this diagnosis from the most basic position confirming that auto-expiration was set up properly, that items on the list were expiring in order, etc. From his further information in his rather insulting and condescending response, it is clear that those items are configured and the issue is with remote filesystems (which I don't use so haven't experienced much).</div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><span id=""></span><br>
<div class="Ih2E3d"><br>> But, in case I'm wrong about your wanting to figure it out for<br>> yourself, I'll mention that one potential approach for "fixing" this<br>> issue was provided in this thread and it all comes down to a<br>
> misconfiguration of your system.<br><br></div>The above is, as far as I can tell, completely wrong. There is no<br>evidence whatsoever that Enigma's storage group is misconfigured.<br><br>I noticed the issue Enigma reported months ago, right after moving to<br>
0.21 and creating a single storage group encompassing three<br>recording directories over two backends: Recordings were being<br>auto-deleted (sometimes almost immediately after beng recorded) even<br>when dozens or hundreds of gigabytes of recordings elsewhere within<br>
the storage group should've been deleted first (based on their<br>priorities or because they were in the Deleted recording group), as<br>clearly indicated in the AutoExpire List. I never filed a ticket<br>because, I figured, such an egregious issue would surely be fixed<br>
ASAP, right? After all, the wiki documentation<br>(<URL:<a href="http://www.mythtv.org/wiki/index.php/Storage_Groups" target="_blank">http://www.mythtv.org/wiki/index.php/Storage_Groups</a>>) and the<br>official documentation it quotes<br>
(<URL:<a href="http://www.mythtv.org/docs/mythtv-HOWTO-9.html#storagegroups" target="_blank">http://www.mythtv.org/docs/mythtv-HOWTO-9.html#storagegroups</a>><br>both say that:<br><br> MythTV will balance concurrent recordings across the available<br>
directories in a Storage Group in order to spread out the file I/O<br> load. MythTV will prefer filesystems that are local to the backend<br> over filesystems that are remote until the local filesystem has 2<br> concurrent recordings active or other equivalent I/O, then the<br>
next recording will go to the remote filesystem. The balancing<br> method is based purely on I/O, Myth does not try to balance out<br> disk space unless a filesystem is too low on free disk space in<br> which case it will not be used except as a last resort.<br>
<br>I read the above as saying that while MythTV normally chooses which<br>directory to store a directory in based on a) local over remote and b)<br>I/O balance, it would use c) free space as the governing criteria if<br>
the directories a) and b) suggested were out of room. As this thread<br>demonstrates, other people interpreted this paragraph the exact same<br>way.</blockquote>
<div> </div>
<div>From the OP, it appears without further information that he had a single recording going at the time of the expiration. In the case of a single recording on what we can assume are all full partitions (each one has about the same amount of free space indicating to me that they are all at capacity), then Myth, based on the Wiki quote, will use the local disk first for the next recording (remember, Storage Groups only dictate where a recording will be stored, not what will be expired). As a result of local disk being chosen, local programs are being expired.</div>
<div> </div>
<div>Seems simple enough to me and exactly as described. I would guess he could test this by running multiple recordings and seeing that they probably get spread to non-local disk after the first or second recording and the resulting expirations take place. I think the suggestion of changing the local weighting is the best and documented solution.</div>
<div> </div>
<div>Kevin</div></div></div>
------=_Part_26508_27740542.1219757825841--
More information about the mythtv-users
mailing list