David, Having just gone through this type of "fix" in our environment (breaking multi-TB drives into smaller chunks), I totally agree with Richard - and we had to do it on W2k3 machines, which theoretically should have been able to handle it.
Your customer needs to understand that the application is "requiring" the O/S to break it for them (or at least promise a high degree of future instability). Regarding the use of journaling - this will solve some of the problem *only* if the machine has a relatively low change rate. If files are being created/updated/deleted in large quantities, you will see frequent journal service crashes. Steve Schaub Systems Engineer, WNI BlueCross BlueShield of Tennessee 423-752-6574 (desk) 423-785-7347 (cell) -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Tuesday, January 10, 2006 10:26 AM To: [email protected] Subject: Re: [ADSM-L] Unable to complete backup of Window's 2000, client failing with - PrivFindDir: No memory to allocate new DirEntry On Jan 10, 2006, at 9:35 AM, David Browne wrote: > I have a Window's 2000 SP4 client (with 8 GB of system RAM) running > TSM > 5.3.0.8 that has two TB of data and around 22 million files in > approximately 11 million directories. > > The data is on one drive and must stay on one drive due to application > requirements. > > Looking for suggestions on how to complete a backup without running > out of memory? David - This is a frequently discussed Windows topic (see the List archives). The essence of your issue is that your file system has outstripped the capabilities of your (old) operating system. Windows 2000 is a 32- bit operating system with artificial addressing constraints, as seen in MS knowledgebase articles like Q142719. You can compensate for this as described in the client manual topic "Configure memory- constrained workstations to run incremental backups". Ultimately, you want a modern operating system, preferably 64-bit. You might also see if the client administrator can effect changes in usage there so that the directory structure makes more sense, as it seems very disproportionate. Richard Sims Please see the following link for the BlueCross BlueShield of Tennessee E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm
