[mythtv-users] Backend crash. Do I have too few hard drives?
mythtv-list at dinkum.org.uk
Sat Dec 4 17:32:48 UTC 2010
On 4 Dec 2010, at 14:57, Paul Gardiner wrote:
> On 04/12/2010 12:52, Andre wrote:
>> On 4 Dec 2010, at 12:14, Paul Gardiner wrote:
>>> On 04/12/2010 11:30, Mike Perkins wrote:
>>>> Paul Gardiner wrote:
>>>>> I've been running MythTv for several years with no real problems.
>>>>> Particularly the backend has been very reliable. Recently I added
>>>>> a Nova S2-HD card to the backend so that I could pick up Freesat.
>>>>> I also added a second HDD, so that I have one for system and one
>>>>> for recordings. I paritioned the recordings disc into two partitions.
>>>>> Can't remember why I did that. Perhaps that's making things worse.
>>>>> Anyway, since the addition, the backend has been on occasion
>>>>> unreliable. Tonight
>>>>> was an example. I had one HD recording on the go, which I was
>>>>> simultaneously watching. That was fine, until two SD recordings started
>>>>> up. That caused the backend to die. I had an empty log file, which
>>>>> happens sometimes. I'll try to get more information next time
>>>>> it happens.
>>>>> Could this be lack of HDD bandwidth?
>>>>> Oh yeah, since the addition, I've upgraded from 0.23.1 to 0.24.
>>>>> That seemed to make the backend more reliable, until tonights
>>>>> crash. A week ago, I rebuilt the backend from the then latest
>>>>> 0.24 fixes, so I'm pretty much up to date.
>>>> Not sure about your crashes, but I doubt that splitting your hard disk
>>>> into two partitions is going to help. While you're making one recording,
>>>> the head is going to be reasonably static over the part of the disk it's
>>>> writing to. Once you start up another simultaneous recording the head is
>>>> going to be thrashing about. Two (or more) partitions guarantees that
>>>> the head is going to have to move a considerable distance each time. Not
>>>> good. Head movement = seek time = delay.
>>>> Now modern disks can probably cope with most of this but why make the
>>>> situation worse when it's not necessary? As a rule of thumb I try to
>>>> arrange one disk (= partition) per tuner. That way, although sometimes
>>>> the storage allocation chooses the same directory, you at least stand a
>>>> chance that each recording will write to a separate disk and the heads
>>>> won't be moving too much.
>>>> (Now the fact that all these will be writing to separate seek tables in
>>>> the database, that's another story. Just hope that mysql does the right
>>> Yes, my thoughts exactly. I still have no idea why I partitioned it.
>>> Although thinking about it again now, for two simultaneous recordings
>>> to the two partitions, it might avoid them getting fragmented, which
>>> would help on playback. I doubt it though. Sounds like it wasn't
>>> a great idea.
>>> Anyway, looks like my problems aren't connected with that. I just tried
>>> for experiment repeating the conditions of the crash. This time no
>>> problems, and I then made it more difficult by watching another HD
>>> channel live. So I was recording 2 SD channels, 2 HD channels, and
>>> playing back 1 of the HD channels. Still no problem.
>>> I guess I'll have to wait for the problem to occur again, and hope
>>> I have logs.
>> A couple of suggestions to check;
>> 1) look at pci latency for the HD-S2 card, some motherboards don't set this correctly, other motherboards benefit from upping this to 64 (us I think). lspci -v will show you it's current setting, usually it's set in the bios in the depths of advanced pci stuff. It can be changed in linux too, from my rc.local:
>> setpci -v -s 05:04.0 latency_timer=40
>> 40 is 64 in hex, you will need to change the PCI id to match your card, in fact I've set all my pci devices to 64, long list of setpci's, seems to work best with a HD-S2.
> Seems to be 32 at the moment. So is the idea to set the latency to
> 64 for every device reported by lspci? I could give that a go.
Only for PCI not PCI express.
>> Don't worry about any PCIe stuff, latency is handled differently or just better, just olde worlde PCI.
>> 2) What SATA controller and drive do you have? I found big problems with an ICH7 combined with samsung drives (HD103UJ, HD154UI& HD501LJ) and a HD-S2, I now have an ICH10 (new MB) and a Silicon Image Adaptec branded controller and all is well. Worth checking drive firmware for updates too, myth seems to be very demanding on drives in a subtle way I'm unable to quantify.
> I do have samsung drives, but the chipset is nVidia MCP55. Hear of any
> problems with that?
Not until now ;-)
I was researching around the controllers and drives I had available but I don't remember anything specific to any nvidia controller.
> When these crashes occur, the machine doesn't need rebooting, it's only
> mythbackend that I have to restart. Does that tell us any more. I guess
> it would help if I could get a log of a crash. Hopefully next time.
Well it's not the same problem I had with the 1TB samsung drives, they would need power cycling before working again.
It's not a Samsung F4 by any chance? If so see this thread: WARNING: Samsung F4 owners / warning. Disable smartmontools
> mythtv-users mailing list
> mythtv-users at mythtv.org
More information about the mythtv-users