[mythtv-users] Basic? NFS question

Bruce Markey bjm at lvcm.com
Thu Feb 9 22:30:37 UTC 2006


Chris Pinkham wrote:
>> Yes, the myth protocol uses a readahead buffer that gives you a
>> local cache of data and is effecient when seeking. This should be
>> more reliable than data transfered by NFS with no knowledge of the
>> application needs. Some people guess that NFS might be better but
>> that's not true.
> 
> Doesn't the readahead thread always run, whether you are streaming from a
> remote backend or reading from a file locally (or via NFS)?

Apparently so. I thought at one time it was only used for buffering
network traffic but not for opening a local filehandle. I stand
corrected.

>> It will look for the file name in the directory in RecordFilePrefix .
>> If you are running a backend on this host, it will already be set.
>> If not, mount the remote disk wherever it is convenient for this
>> machine then run mythtv-setup and set that path on the second page
>> of General as the "Directory to hold recordings".
> 
> This used to be the case, but was changed sometime after 0.18 I think.
> The code now checks the backend's recording directory to see if the
> file exists in that directory locally, so you shouldn't have to run
> mythtv-setup and setup a local recording directory. If you do have
> a local RecordFilePrefix configured, that directory will be checked
> also.

RecordFilePrefix is the backend's recording directory so as the same
thing, what you've said is confusing. What I said is, if a backend
had been setup for this host, the RecordFilePrefix (backend's recording
directory) for this hostname would exist and the frontend would look
for the file in that directory. This has been true since about 0.8 .

If the host has only been used as a frontend and mythtv-setup was
never run on the host, there would be no RecordFilePrefix for the
hostname. Two ways to rectify this would be to run mythtv-setup to
set the "Directory to hold recordings" (which is RecordFilePrefix)
or to edit the settings table manually to add one.

>> For me, I'd never read from a remotely mounted disk as a local path
>> over using the application specific protocol.
> 
> In cases where you have a dedicated NFS server, using NFS can be
> faster than the native protocol because using the native protocol
> requires sending the data over the network twice.  The first time is
> over NFS from the NFS server to the backend, then a second time via
> the Myth protocol from the backend to the frontend.  It is more

True but this is a different scenario. If someone has a backend
writing files to a remote NFS dir. they sure haven't been taking
my advice so it doesn't matter what I say ;-).

M is a master and S is a slave. S is recording and being watched
from a frontend at M. If S writes to a local disk and there is a
network problem, the problem can be fixed and you can restart the
playback at M. However, if S is writing to an NFS mount from M and
there is a network problem, the file will be damaged and you can
never play it back from any host. Therefore, on my master with
three slaves, I always write to local disks.

[I also don't like to write multiple files to the same spindle and
this will come up with multiple directories after 0.19. If the disk
heads are positioned and a video file is being written, it can fill
the cylinder, track to track seek then fill the next cylinder. Very
efficient. If more than one file is being written to the same physical
disk, the disk has to reposition from the end of one file to the end
of the other. This usually takes 8-15ms while the disk isn't writing
to either file. The difference in throughput between streaming data
and writing small chucks to multiple locations can be as much as 100X.
Therefore, in addition to network issues, I want each slave's file
written to it's own disk.]

In your example, you are suggesting that there is an NFS fileserver N
that M and S have mounted. If so, the frontend on M will find the
file in the RecordFilePrefix dir and will not request the file from
S and will not send the data twice. I hope no one is doing this anyway.
Master Backend Overried is based on the assumption that any salve
using NFS mounts are mounting the disks local to the master. Now, if
someone has a slave that is mounting the file directory over NFS to
a directory that is not visible to the master, please post so we can
all have a good laugh ;-).

> efficient in this case to just read the file directly from the NFS
> server.  This is one of the reasons I originally added code to
> allow reading the file directly (via NFS, CIFS, etc.) if it existed
> rather than using the Myth protocol, because I have used a dedicated
> NFS server since I started using Myth back around v0.7.

Unless you were referring to something else, the "0.18" above must have
been a typo. I remember this being shortly after the split around 7 or 8.

> For the case of a non-dedicated NFS server that is just sharing out
> the recordings directory on the backend itself, then it may be better
> to use the Myth protocol so I'll defer to your previous comments on that
> case.

It's probably fine either way. I just get a little uncomfortable when
people try to say that you have to NFS mount or assume you want to NFS
mount for better performance when that just isn't true.

--  bjm


More information about the mythtv-users mailing list