<div><span class="gmail_quote">On 1/9/06, <b class="gmail_sendername"><a href="mailto:f-myth-users@media.mit.edu">f-myth-users@media.mit.edu</a></b> <<a href="mailto:f-myth-users@media.mit.edu">f-myth-users@media.mit.edu
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I suspect that the answer to this question is, "Don't do that, then,"
<br>but in case anyone has any suggestions:</blockquote><div><br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The question is, can I do better? I don't imagine I'll often be
<br>rsyncing the entire disk, but I will certainly be rsyncing the delta<br>since the last rsync, and I'd rather not have to worry about that<br>disrupting recordings. (That's a bit harder to test under load, since<br>the deltas will vary, but I'll attempt it to ensure that rsync's
<br>scanning phase isn't enough to cause disruption.) Current NFS mount<br>options are rsize and wsize of 8192; would increasing these help on a<br>100baseT hub, or just lead to more fragment reassembly? (Actually,<br>the hub itself is an SMC 8508T gigabit hub with jumbo packet support,
<br>but the NICs on the CPUs are only 100 megabit.) Other NFS options are<br>soft & nfsvers=3, which are pretty standard.<br></blockquote><div><br><br>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.
<br></div><br></div>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.
<br><br><br>