[mythtv-users] Missing SBE locks/hangs MBE???

[Michael T. Dean]

On 02/08/2013 05:12 PM, Michael Watson wrote:
> On 9/02/2013 5:18 AM, Jonathan Larson wrote:
>>
>> Hello All,
>>
>> I’ve got 5 SBEs that stay on 24/7 normally. They all connect to a 
>> tuner-less (except for a dummy tuner) MBE virtual machine. Yesterday, 
>> one of the SBE’s had a hardware failure and stopped responding. 
>> Shortly afterwards the MBE stopped responding via its status port or 
>> mythweb. And shortly after that the other SBEs also gave up because 
>> they couldn’t contact the MBE. Basically, a single hardware issue on 
>> 1 SBE brought down the whole system.
>>
>> The storage for recordings is all on the SBEs—2 disks each, defined 
>> in the storage groups setup on the MBE. The SBE’s are also 
>> cross-mounted via NFS, and they mount a NFS share on the MBE for 
>> access to the post-processing user scripts. All those mounts are 
>> controlled via autofs, which uses the following options: 
>> -rw,noatime,nodiratime,soft,nfsvers=3
>>
>> I’d really appreciate any advice on how to troubleshoot this cascade 
>> failure. I really want to be able to bring down a SBE without an 
>> adverse effects to the rest of the system. I wonder if this could be 
>> caused by the cross mounting of the storage directories via NFS, and 
>> if so, are there any NFS mount/share options that I could use to make 
>> them fail gracefully—maybe a shorter timeout period?
>>
>> Any help would be appreciated.
>>
>>
> Yep, I had the same problems when I had my storage distributed on 
> SBE's (and mounted by NFS). Your only options are to centralize your 
> storage on the MBE (or a NAS Device), or not mount them via NFS.

Ah, so this is actually a problem of NFS's default "block applications 
until I/O is possible", which, perhaps, causes problems for MythTV 
(which expects to be able to write to its storage directories)?  Is this 
related to the soft/hard timeout option, where hard is NFS default 
because soft timeout can cause silent data corruption, but hard 
completely blocks the client--where in MythTV's case, that may well 
result in it filling up its buffers/memory with recording data until it 
crashes or is OOM-killed or ...?

Mike