Re: Large file system on HP-UX or SGI

Also,

        Watch ps -el | sort +9n during the failure (script it of course) and
see how much memory the process gets.
        Watch also the total memory on the system.

        See which one you are hitting.  Remeber ps -el is given in blocks.

        With memory efficient backup, the number of files in a sinle
directory is your concern.  The is as opposed to without it and the number
of files in a filespace being the key number.

Jeff

> -----Original Message-----
> From: Seay, Paul [SMTP:seay_pd AT NAPTHEON DOT COM]
> Sent: Saturday, February 09, 2002 1:00 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Large file system on HP-UX or SGI
>
> 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:Thomas.Denier AT MAIL.TJU DOT EDU]
> Sent: Saturday, February 09, 2002 12:12 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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?


**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the individual or entity to
whom they are addressed.  If you have received this email
in error destroy it immediately.
**********************************************************************