On 1/9/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]
> wrote:
Have you tried using NFS over TCP? It won't help the dirvish I/O on local disk, but could improve reliability of the NFS mount for your SBE.
A nice addition to your setup would probably be a dedicated NFS server. This doesn't eliminate dirvish I/O as a problem entirely, but confines it to the machine running a backup at the time. Even assuming your backups go to the NFS server, you'll still be better off this way I think.
I suspect that the answer to this question is, "Don't do that, then,"
but in case anyone has any suggestions:
The question is, can I do better? I don't imagine I'll often be
rsyncing the entire disk, but I will certainly be rsyncing the delta
since the last rsync, and I'd rather not have to worry about that
disrupting recordings. (That's a bit harder to test under load, since
the deltas will vary, but I'll attempt it to ensure that rsync's
scanning phase isn't enough to cause disruption.) Current NFS mount
options are rsize and wsize of 8192; would increasing these help on a
100baseT hub, or just lead to more fragment reassembly? (Actually,
the hub itself is an SMC 8508T gigabit hub with jumbo packet support,
but the NICs on the CPUs are only 100 megabit.) Other NFS options are
soft & nfsvers=3, which are pretty standard.
Have you tried using NFS over TCP? It won't help the dirvish I/O on local disk, but could improve reliability of the NFS mount for your SBE.
_______________________________________________ mythtv-users mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
