[mythtv-users] NFS and remote backend
evuraan at gmail.com
Tue Jan 8 21:18:03 UTC 2008
Instead of nfs, use compressed ssh port fwding between your myth F/E
and B/E - of course, you'll burn slightly more calories running ssh to
compress/decompress, but that should let you live with your thin net
Here's a small howto:
ssh is more secure, plus in this way, mysqld and backend need to
listen only on 127.0.0.1
On Jan 6, 2008 1:24 PM, R. G. Newbury <newbury at mandamus.org> wrote:
> 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
> 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.
> mythtv-users mailing list
> mythtv-users at mythtv.org
More information about the mythtv-users