[mythtv-users] Slave backend with shared NFS storage thinks it has its own disk.
cpinkham at bc2va.org
Thu Apr 26 19:14:57 UTC 2007
* 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
More information about the mythtv-users