Help Me Optimize for MythTV (simultaneously reading and writing 2+ GB mpeg2 files)

[mattlach]

So just a quick reply here. I have my MythTV on a bare metal server along with my FreeNAS box as well. My MythTV has a Intel Core 2 Duo in it (not sure on the specs as I stuck it in my crawlspace over a year ago and haven't touched it) with 4GB of ram and my FreeNAS is a Xeon L5420 with 12GB of ECC Ram. I know I am no where near the hardware that the OP has here I could only wish lol. However I too experience the same exact issue with watching the file while its being recorded. My LiveTV goes to local storage however my recordings go to the NAS on a 1TB mirror. I didn't want to put the Myth drives into the main pool due to how active these drives are. So I can confirm that this does happen to me as well, I also have the flag turned on to search for commercials while its recording. I've recorded up to 4 shows at once so far I haven't attempted to max my tuners out at 6 recordings at once although I'm sure that everyone could handle it well. I sometimes wonder if the MythTV jail were to come back if that would fix this? Just a thought.

Thank you for chiming in!

So, your MythTV is on bare metal. Is FreeNAS on bare metal as well?

This might dispell that it is related to Virtualization once and for all.

 

[mattlach]

Everything you have discussed could be attributed to the copy on write file nature of zfs. Every time the file is written to a new copy is made which will not allow access until it is completed. NFS has an annoying behaviour of locking the file system while it is being used which could easily timeout the playback machine. In the case of your NFS settings they are woefully small for rsize and wsize, please change them to a reasonable value. I have no idea why they leave that as the defaults as they are only suitable for a 10mbit network not a 10G network. The other thing you could try is mounting the share using a different protocol eg cifs or sshfs and see if the behaviour persists.

Now something like this is what I was suspecting all along. Thank you for this information!

I was intentionally using conservative wsize and rsize numbers in order to avoid stalls that some hardware sees when you go to the full 32k size, but I have tried 32k as well, without success.

I will test it with CIFS, and maybe with iSCSI (though I'd hate to have to create drive images, rather than just have the files reside in the pool directly)

 

[mattlach]

Everything you have discussed could be attributed to the copy on write file nature of zfs. Every time the file is written to a new copy is made which will not allow access until it is completed. NFS has an annoying behaviour of locking the file system while it is being used which could easily timeout the playback machine. In the case of your NFS settings they are woefully small for rsize and wsize, please change them to a reasonable value. I have no idea why they leave that as the defaults as they are only suitable for a 10mbit network not a 10G network. The other thing you could try is mounting the share using a different protocol eg cifs or sshfs and see if the behaviour persists.

I still haven't gotten around to testing SMB instead of NFS, but I came across someone on the Ubuntu forums in the MythBuntu section who was having the same issue, and relayed your thoughts there. He tried SMB and said his problems went away, so it seems like it is a solution! Thanks for the suggestion!