[mythtv-users] NFS and remote backend
R. G. Newbury
newbury at mandamus.org
Sun Jan 6 18:24:32 UTC 2008
Brian wrote:
> jongi wrote:
>> David Brodbeck wrote:
>>> On Jan 1, 2008, at 8:31 AM, jongi wrote:
>>>
>>>> Mike Barnard wrote:
>>>>>> Both systems are F8 but the nfs is painfully slow between them. ftp
>>>>>> though runs at over 1MB/s and nfs is nowhere near that speed.
>> /etc/fstab
>>
>> 10.0.0.3:/nfs4exports/share1 /mnt/mythtv/media/ nfs rw
>>
>> /etc/exports
>>
>> /nfs4exports/share1/ *(rw,async,all_squash)
> You can try by increasing the buffer size by adding rsize=$kb,wsize=$kb
> in the options section where $kb is the amount of buffer in kilobytes.
> IIRC, Linux kernels over 2.4 default to an 8k buffer. Maybe try 32k
> ($kb=32768)?
>
> I've found that SCP, NFS and Samba all operate at the same speed (pretty
> much). I'm not sure how FTP speed places in that group. Maybe try a test
> using SCP to isolate if it's a network problem or NFS problem?
I think that any of these methods should run at nearly the same raw
speed. It's the extras of overhead which slow some of them down.
I picked up some pointers somewhere and this is what I use between my
systems. This is the laptop nfs mounting the myth box. With this setup,
my limiting factor is the wireless G rate if I am operating wireless, or
the wire speed rate if plugged in.
myth.whatever.net:/video /mnt/mythvid nfs
users,tcp,rsize=4096,wsize=4096,soft,intr,actimeo=0,nfsvers=3
Various settings affect all this.
1) The MTU setting is raised to 4160 in the Network Device settings.
This is 64 bytes (overhead allowance) above the 4096, which are the
send/receive buffer sizes. This is now the max 'packet' size. (I know
its not really the packet size, but that's as good a concept as any for
this use). This cuts down on comm overhead where tcpip has to chop and
re-assemble chunks of bytes before sending them on the the system.
The soft,intr are supposedly faster than the other choices...I cannot
even remember exactly what they are.
The actimeo=0 is important. This tells the system not to write the
accesstime to the file on each access. This is a major time overhead on
even read access to a file.
I didn't benchmark this but it does help.
Geoff
More information about the mythtv-users
mailing list