[mythtv-users] Slave backend with shared NFS storage thinks it has its own disk.

[Chris Pinkham]

* On Thu Apr 26, 2007 at 07:13:15PM +0100, Tim Phipps wrote:
> Filesystem           1K-blocks      Used Available Use% Mounted on
> /dev/mapper/vg1-lv1  459100320 360828500  93607624  80% /home

> nfs:/home            459100320 360828480  93607648  80% /home

I believe this is similar to what people were seeing.  It was fixed by
changing the order of some multiplication and division in the code.  After
I put the fix in -fixes earlier this week, Jarod merged it into the 0.20.1
tag branch, so it will be in 0.20.1 when that version is released.

> out by 20k/24k. Could this be due to different block sizes? If so how do I 
> set the blocksize on an NFS mount?

I think nfs sets the block size to be one of the read/write sizes, but I'm
not sure.  You can set these using "-o rsize=8192,wsize=8192" or something
similar on your nfs mount command.

> Would this also explain why I'm seeing occasional playback pauses? The 
> frontend is on the slave and most of the recordings are made on the master. 
> Mplayer on the frontend has no problems with playback over NFS, so I'm just 
> speculating that the frontend may be using the Myth protocol to play 
> recordings rather than NFS.

I don't think this is related, although if you haven't tuned your nfs mounts
or fileserver, you should look at doing so.  You can find more info by
searching the archives for something like "nfs mount options".  The place
where the bug was only affected the disk space calculations, it has nothing
to do with playback or streaming, etc..  Since Myth viewed the mounts as
having different amounts of space, it thought they were actually on different
disks.

--
Chris