What is the OS?

Could Journaling or some form of, be helpful here?

_____________________________
Ian Smith
SAN/TSM Specialist
IT Infrastructure
Rabobank International
Thames Court, One Queenhithe
London EC4V 3RL
t: +44 (0)20 7809 3046
f: +44 (0)20 7809 3599
m: +44 (0)7843 689914
Mailto: [EMAIL PROTECTED]


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Richard Sims
Sent: 21 April 2006 13:38
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Tivoli DB limit

On Apr 20, 2006, at 5:28 PM, Gaurav Marwaha wrote:

>       We have a huge file system with about 30 to 50 million files to
be 
> backed up, the incremental backup does the job, but takes too long to 
> complete, out of these 50 million files, only 20000 or so actually 
> change. So the scanning runs sometimes into 24 hour window and the 
> next scheduled backup starts without actually completing the previous 
> one.

Gaurav -

You may be new to TSM and not realize that this question has been
pursued many times in this forum. You can best review past postings at
www.mail-archive.com/adsm-l@vm.marist.edu/ .

This is formally known as the "Many small files" problem. See that entry
in http://people.bu.edu/rbs/ADSM.QuickFacts or http://
www.tsmwiki.com/tsmwiki for collected information.

> Someone tells me that the Tivoli DB can take only 100million objects 
> for tracking and filist might not be a correct way to do it. He says 
> there is DB2 lite running behind TSM and that has this limit?

Your information source is faulty. I'd advise more authoritative
references, as found on the IBM Web site and in documented referenced in
mailing list postings.

It is more typically the case that the client is "limited" in running
out of the amount of memory needed to accommodate the Active files list
it gets from the server at the start of Incremental backup processing.
It behooves a client which serves a highly elevated data complement like
this to run a 64-bit version of the operating system for that platform,
to best deal with the volumes of metadata that it needs to be able to
handle. This provides the expanse needed for holding such arrays in
memory.

  Richard Sims
_____________________________________________________________

This email (including any attachments to it) is confidential, legally 
privileged, subject to copyright and is sent for the personal attention of the 
intended recipient only. If you have received this email in error, please 
advise us immediately and delete it. You are notified that disclosing, copying, 
distributing or taking any action in reliance on the contents of this 
information is strictly prohibited. Although we have taken reasonable 
precautions to ensure no viruses are present in this email, we cannot accept 
responsibility for any loss or damage arising from the viruses in this email or 
attachments. We exclude any liability for the content of this email, or for the 
consequences of any actions taken on the basis of the information provided in 
this email or its attachments, unless that information is subsequently 
confirmed in writing. If this email contains an offer, that should be 
considered as an invitation to treat.
_____________________________________________________________

Reply via email to