We recently ran into this problem on an SGI box with about 5 million files in a 1TB file system. Support indicated that there is a memoryefficientbackup option, but I did not place the call.
This is from the manunal. Configure Memory-Constrained Workstations to Run Incremental Backups Incremental backup performance suffers if the workstation has a low amount of memory available prior to starting the backup. If your workstation is not memory constrained, specify the memoryefficientbackup No option in your client options file dsm.opt to provide the best performance. If your workstation is memory constrained, specify the memoryefficientbackup Yes option in your options file. Specifying Yes reduces memory consumption but increases backup time. When you specify Yes, Tivoli Storage Manager backs up only one directory at a time. If performance remains poor, check your communication buffer settings and the communication link between your workstation and the server. What support said was to backup the directories first using the -dirsonly option. Then the files. Also, look at the memoryefficientbackup option. This unfortunately is a dsm.opt option on the client so you have to change it for all directories. I have no idea how long this is going to extend the backup. However, this was a very large server, so a ulimit change may be what is needed and let it suck up more memory. We are still working on this problem. Like you said there is no documentation on how much memory is necessary to backup such a large file system. -----Original Message----- From: Thomas Denier [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 09, 2002 12:12 PM To: [EMAIL PROTECTED] Subject: Large file system on HP-UX We have an HP-UX 11 client system running the 4.1.2.0 client. This system has one file system with about 3.1 million files. The number of files has been growing, and was only 2.9 million a week ago. The backups for this system recently started failing with 'User abort' messages. A search of the ADSM-L archive revealed that our client has a bug that causes a number of different problems to be misreported as user aborts. I susoect a memory shortage. The README file for the client states that the maxdsize kernel parameter may have to be increased for large file systems. Tivoli being Tivoli, there is no quantitative information about the relationship between file system size and the necessary maxdsize value. We have maxdsize set to 512 megabytes, which is eight times the default value. Is there a later client level that fixes the error reporting bug and is otherwise fit for production use? Is it possible that we need a still larger value for maxdsize?
