ADSM-L

Re: FSCK problem on TSM

2006-09-26 08:24:48
Subject: Re: FSCK problem on TSM
From: Adrian Compton <adrianc AT ASPENPHARMA DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 26 Sep 2006 14:23:02 +0200
Hi
My next storage pool for DISKPOOL is the OVERFLOW storage pool. It is
backed up to Offsite daily as with DISKPOOL. I guess I am covered in the
interim then.

Thanks for your assistance.

Regards,
Adrian Compton



             "Bos, Karel"
             <Karel.Bos@ATOSOR
             IGIN.COM>                                                  To
             Sent by: "ADSM:           ADSM-L AT vm.marist DOT edu
             Dist Stor                                                  cc
             Manager"
             <[email protected]                                     Subject
             .edu>                     Re: [ADSM-L] FSCK problem on TSM


             26/09/06 14:02


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






Hi,

The next stg parm should be working. Overflow, I don't know.

Regards,

Karel


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Adrian Compton
Sent: dinsdag 26 september 2006 13:59
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: FSCK problem on TSM

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

(See attached file: disclaimer.txt)

Attachment: disclaimer.txt
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>