=> On Wed, 1 Oct 2003 11:56:41 -0400, Mark Trancygier <[EMAIL PROTECTED]> said:
> Thanks Allen. > I think the virtualmountpoint option will be the best way to go, as we have > a pretty hearty SAN environment and I don't believe we have client disk > contention. Are you aware of any limitations on the number of > virtualmountpoints per client ? I don't think there's an inherent limitation, but I'd say 'Don't go nuts'. There's a tradeoff between speed, parallelism, and manageability here. We've got a "partition" (not filesystem, an application-layer distinction) model that presents 40 blindingly obvious virutal filespaces per machine; if it weren't blazingly obvious because of the application structure, I'd consider it overkill. You only need enough partitioning to permit you to get your maximum interesting parallelism for the duration of the backup. So if your returns diminish at three threads, then three paritions precisely equal is your best case. Four, on the other hand, could be considerably worse than three. Visualize; four partitions getting serviced by three threads: t-> Thread 1 : 111111111111111444444444444444444 Thread 2 : 222222222222222 Thread 3 : 333333333333333 By making your partition count just wrong, you've wasted a lot of possible effort. - Allen S. Rout