ADSM-L

Re: Incremental backups on file systems that contain a large number offiles

2003-10-01 16:06:49
Subject: Re: Incremental backups on file systems that contain a large number offiles
From: asr AT UFL DOT EDU
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 1 Oct 2003 16:04:54 -0400
=> On Wed, 1 Oct 2003 11:56:41 -0400, Mark Trancygier <TrancygM AT 
TRINITY-HEALTH DOT ORG> 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

<Prev in Thread] Current Thread [Next in Thread>