You get to pick the location:

MEMORYEFFICIENTBACKUP   DISKCACHEMETHOD
DISKCACHELOCATION       \path

On Thu, Oct 9, 2008 at 11:48 AM, Zoltan Forray/AC/VCU <zforray AT vcu DOT 
edu>wrote:

> Are there any hidden controls on where it puts the "diskcache"?  The book
> doesn't seem to indicate anything for MEMORYEFFICIENT other than
> YES/NO/DISKCACHEMETHOD?
>
> The node hasn't been backing up.  That is how this issue saw
> daylight....when I contacted the client about their backups
> failing....they said "yeah....we have been seeing these errors in the logs
> and didn't know what to do about them", not that they ever thought of
> contacting me......
>
>
>
> Wanda Prather <wprather AT JASI DOT COM>
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 10/09/2008 11:41 AM
> Please respond to
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
> To
> ADSM-L AT VM.MARIST DOT EDU
> cc
>
> Subject
> Re: [ADSM-L] ANS5013E Not enough memory for backup operation
>
>
>
>
>
>
> Hi Zoltan,
>
> I've seen the problem on clients with as few as 10m files.
> When you do a typical incremental backup, the first thing that happens is
> that the server pushes down to the client a list of the "active" backup
> set.
>
> The problem is with the client handling that list.
> I'm surprised you aren't also having problems with the client completing
> backups on time, having to navigate a filesystem that large.
>
> To fix the memory issue, the quick and dirty is MEMORYEFFICIENT
> DISKCACHEMETHOD.
> That lets the client use disk space to store that humongous list.  Never
> had
> it cause a problem, nor does it seem to slow things down that much.
>
> If you still have issues, and the daily file change rate is low, then go
> to
> journaling.
>
>
> W
>
> On Thu, Oct 9, 2008 at 11:23 AM, Zoltan Forray/AC/VCU
> <zforray AT vcu DOT edu>wrote:
>
> > Is there a "realistic" maximum number of files a Windows client can
> handle
> > before having this kind of problem?
> >
> > This system has 30-40 MILLION objects/files.
> >
> > Not sure if this error is caused by the large number of files or a
> client
> > problem.  They are currently running the 5.5.0.6 client. Recommended at
> > least going to the 5.5.1.1 level before we troubleshoot this problem,
> > further, since they are also getting the dreaded "
> >
> >
>
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup\DRM.
> > RC = 13." error which IIRC, the 5.5.1.x client resolves/addresses.
> >
> > If this doesn't help, what other recommendations are there to handle
> this
> > situation?  MEMORYEFFICIENTBACKUP ?   Multiple backup/node definitions
> to
> > run different backups for each drive (1-drive has 26M and another has
> > 11M).
> >
>