[mythtv-users] mythbackend crashes

Blues Guy bluesguy at stny.rr.com
Tue Nov 23 02:40:09 UTC 2004


glen martin wrote:

>On Wed, 2004-11-17 at 12:13, Buchanan, Paul (West) wrote:
>  
>
>>On Wednesday, November 17, 2004 1:20 PM,
>>mythtv-users-bounces at mythtv.org wrote: 
>>    
>>
>>>On Tue, 2004-11-02 at 14:33, Andrew Plumb wrote:
>>>      
>>>
>>>>--snip--
>>>>2004-11-01 22:29:27 IOBOUND - blocking in ThreadedFileWriter::Write()
>>>>2004-11-01 22:29:28 IOBOUND - blocking in ThreadedFileWriter::Write()
>>>>--end-snip--
>>>>        
>>>>
>>>I've had three crashes  in the past 24 hours like
>>>this.  In only the third case could I read any
>>>console output, and in that case, after the IOBOUND
>>>message I got (paraphrased):
>>>
>>>      
>>>
>><snip>
>>    
>>
>>>For the record, I'm using XFS for video files,
>>>ext3 for some other partitions, software raid,
>>>no partitions over 60% full.
>>>      
>>>
>>My .16 backend will hang (no segfault, just stops responding) with IOBOUND messages when my XFS /video partition reaches around 90% full.  I see that you are only 60% full, but thought I'd comment anyway.  XFS has a tendency to drastically reduce in performance as the partition fills up.  Although I thought I could live with keeping my partition 85% free, I may end up switching to ext3 to avoid the instability.  You may want to investigate your file system performance, as the Backend seems unhappy when slowdowns occur.
>>    
>>
>
>  
>
Ext3 is a bad idea.  It handles large deletes *very* poorly (i.e. you'll 
get even more IOBOUND errors when you delete large files while recording 
on Ext3.)  Try JFS instead.  Works just as well as XFS without the 90% 
full headaches.  JFS doesn't have all the fancy shrink/grow options like 
XFS does though...


>This is interesting, in that I've got the lvm and raid
>in between the backend and the real disc. So cpu challenges
>become filesystem bandwidth problems. Hrrrm. Need to rethink
>this perhaps (or make damn good and sure I never get close
>to pegging the cpu). May be implications for transcoding
>(which I'm not doing presently, but likely will in future).
>
>  
>
I've got an 850MHz PIII running LVM over software RAID5 on four 250GB 
SATA drives with three PVR-250's.  I don't have any IOBOUND problems 
using FC2 with Axel's latest Myth RPM's and ivtv-0.2.0-55_rc2j, even 
when running all 3 cards and moving two simultaneous 4GB files locally 
across partitions.  In my testing, once I started a third simulataneous 
large file, it started to block, but that stress test was beyond 
anything I've encountered in real life.  FWIW - With 100zz I did get 
IOBOUND errors, and the "stealing a buffer" message.  The buffering 
between those two versions is significantly different, and the 2.0rc2 
version is much better.  Oddly enough, with 100zz my backend wouldn't 
die immediately, and live TV usually still worked, but new recordings 
wouldn't start.  Restarting the backend would fix it, but it would 
always happen again in a day or two.  Upgrading to ivtv-0.2.0-55_rc2j 
fixed it for me.



More information about the mythtv-users mailing list