The file system is an Enhanced JFS2 file system. It is 1.15TB. It is on a
EMC SAN, and mounted as /backup on the TSM LPAR. It consists of a number of
LUNS on the EMC SAN. It contains all of our DISKPOOLS. My logs are now fine
as I allocated more log space using dsmfmt and the TSM Server could
restart. My Logs andTSM DB's are on  seperate filesystem i.e /usr
After rebooting the LPAR, AIX wont mount the filesystem because of a
superblock error. We have determined that an FSCK is running, and
apparently this can take days on a large file system.
I see now that we should have a large Raw Logical Volume to overcome these
contraints.

To keep Tivoli running we have had to exclude this FS (/backup/) from
mounting, but are now running without the DISKPOOL. Hence my question about
the OVERFLOW storage pool automatically becoming the recipient in place of
the DISKPOOL without having to change any parameters.

Apologies for my explanation, but I have only been working with TSM for 5
months now although I have training behind me.

Thanks in advance.

Adrian Compton




             Richard Sims
             <rbs AT BU DOT EDU>
             Sent by: "ADSM:                                            To
             Dist Stor                 ADSM-L AT vm.marist DOT edu
             Manager"                                                   cc
             <[email protected]
             .edu>                                                 Subject
                                       Re: [ADSM-L] FSCK problem on TSM

             26/09/06 13:07


             Please respond to
             "ADSM: Dist Stor
                 Manager"
             <[email protected]
                   .edu>






You're not giving us enough information to understand what the actual
problem is there. Disk storage pool space and Recovery Log space are
very different things and very much should be in very different
places, having different service and recovery needs, including
mirroring for the TSM database and recovery log.

With AIX, you should ideally be using Raw Logical Volumes, as
described in the Admin Guide and other TSM documentation, such as the
Performance Tuning Guide.  This will eliminate all the file system
issues and greatly facilitate disaster recovery. Always thoroughly
review vendor configuration recommendations before proceeding with an
implementation. And always implement monitoring, to avoid needless
disruptions like this.

Again, I won't add further recommendations, absent the solid
information needed to provide proper guidance.

    Richard Sims

On Sep 26, 2006, at 6:29 AM, Adrian Compton wrote:

> Hi
>
> Yesterday my TSM server (p500 LPAR AIX 5.3) had the TSM Logs run
> out of
> space. In hind sight, the Server was bounced and I now have  fsck
> running
> forever almost as if in a loop. At present it would take days as the
> filesystem concerned is 1.150TB.
>
> Apparently we need to patch the OS as the FSCK gets into a loop,
> and has to
> complete the checks of the superblocksbefore it can be mounted. This
> filesystem contains my DISKPOOLS.
>
> My questions are/
>
> 1. Will any clients that normally go to DISPOOL now automatically
> go to
> overflow until the filesystem comes backup.
> 2. what is the recommended max filesystem size to prevent this long
> FSCK.
> 3. Is there any other way to resolve this long wait for the check to
> complete.
>
> Regards
>
> Adrian Compton