[mythtv-users] mythtv + nfs = bad?

[Dale Pontius]

Dale Pontius wrote:
> Alex Pearson wrote:
>> mythtv-users-bounces at mythtv.org wrote on 09/05/2009 19:56:46:
>>
>>> From:
>>>
>>> David Brodbeck <gull at gull.us>
>>>
>>> To:
>>>
>>> Discussion about mythtv <mythtv-users at mythtv.org>
>>>
>>> Date:
>>>
>>> 09/05/2009 19:15
>>>
>>> Subject:
>>>
>>> Re: [mythtv-users] mythtv + nfs = bad?
>>>
>>> Sent by:
>>>
>>> mythtv-users-bounces at mythtv.org
>>>
>>> Alex Pearson wrote:
>>>> Hi All,
>>>>         I'm not sure if this will help anyone, but I found nfs 
>> unstable
>>>> on my box at home (which runs a number of nfs root'd servers as well 
>> as
>>>> mythtv storage), I resolved the issue by setting the clients to tcp 
>> and
>>>> also increasing the block size.  I now use the following mount 
>> options:
>>>>                 defaults,tcp,rsize=8192,wsize=8192 for general 
>> servers.
>>>>                 defaults,tcp,rsize=8192,wsize=8192,actimeo=0 for 
>> mythtv.
>>> If you're running nfsv3, I think 8192 may actually be *smaller* than the 
>>
>>> default block size.  So you may have reduced it, not increased it.
>>>
>>
>> Its interesting you say that, I didn't spend a lot of time looking 
>> into the block sizes (just dug in and had a play with them), but from 
>> the man page:
>>
>>                       "If an rsize value is not specified, or if the 
>> specified rsize value is larger than the maximum that either  client  
>> or server can support, the client and server negotiate the largest 
>> rsize value that they can both support."
>>
>>
>> So you may well have a point!  Now I don't know whether I increased, 
>> or decreased, the block size!  Oh well... If its not broke (which it 
>> isn't now)
>>
>>> I'm not going to argue with it if it fixed your problem, but I now 
>>> tend to stay away from rsize and wsize tweaks.  They were necessary 
>>> for older 
>>
>>> NFS versions, but people have kept doing them as a sort of cargo cult 
>>> ritual even on newer versions.
>>
>> I guess I'm a member of the cult ;-)  Cool, never been in a cult 
>> before....
>>
> I'm running with:
> nfs4    rw,hard,intr,rsize=32768,wsize=32768,nosuid,nodev
> So the sizes can be bigger than 8192, and I guess I'm a member of the 
> cult, too.  Smaller cult even, because I'm running nfs4.
> 
> Prodded by this thread, I'm experimenting with rebuilding the kernel on 
> my backup server.  I tried applying the patch stuff, without luck.  The 
> patch won't apply directly, I suspect because the web page I downloaded 
> from did some whitespace damage.  I tried making the changes manually 
> and messed something up.  So I'm working on the theory that there is 
> some sort of fix in 2.6.29, and have copied svcsock.c and svc_xprt.c 
> from a client machine.  I've had to backtrack some changes out of 
> "svc_check_conn_limits", but finally have a clean compilation. Won't 
> know if it works until I make_modules_install, reboot and try using nfs 
> off of that machine, but at least I just got this far.
> 
> More to come...
> 
As mentioned before, I tried applying the patch, and failed.  I then 
took svcsock.c and svc_xprt.c from a 2.6.29 kernel, copied them back 
into a hardened 2.6.28 kernel, fixed some misc errors, and had nfs 
running, again.  In the process, I upped the nfs threads from 8 to 16 as 
someone here suggested.  I checked it out on my test server, and today 
put it into my main server.

It's better, but not perfect.  There has been a lot of fuss about 
firefox, its use of the sqlite database, and bad interactions with the 
filesystem.  I suspect that in the case of nfs it's downright 
pathological.  So far after the fix I've only had nfs stalls when 
running firefox, but don't really have enough time in to be sure.

There is also a patch to move firefox's sqlite onto tmpfs, and 
inotify/time based backup into the persistent filesystem.  I may try 
that fix, too.

Dale