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"
             <[EMAIL PROTECTED]
             IGIN.COM>                                                  To
             Sent by: "ADSM:           ADSM-L@vm.marist.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:[EMAIL PROTECTED] On Behalf Of
Adrian Compton
Sent: dinsdag 26 september 2006 13:59
To: ADSM-L@VM.MARIST.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
             <[EMAIL PROTECTED]>
             Sent by: "ADSM:
To
             Dist Stor                 ADSM-L@vm.marist.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)
ÿþDit bericht is vertrouwelijk en kan 
geheime informatie bevatten enkel

bestemd voor de geadresseerde. Indien 
dit bericht niet voor u is bestemd,

verzoeken wij u dit onmiddellijk aan 
ons te melden en het bericht te

vernietigen.

Aangezien de integriteit van het 
bericht niet veilig gesteld is middels

verzending via internet, kan Atos 
Origin niet aansprakelijk worden 
gehouden

voor de inhoud daarvan.

Hoewel wij ons inspannen een virusvrij 
netwerk te hanteren, geven

wij geen enkele garantie dat dit 
bericht virusvrij is, noch aanvaarden 
wij

enige aansprakelijkheid voor de 
mogelijke aanwezigheid van een virus in 
dit

bericht.

 

Op al onze rechtsverhoudingen, 
aanbiedingen en overeenkomsten 
waaronder

Atos Origin goederen en/of diensten 
levert zijn met uitsluiting van alle

andere voorwaarden de 
Leveringsvoorwaarden van Atos Origin 
van toepassing.

Deze worden u op aanvraag direct 
kosteloos toegezonden.

 

This e-mail and the documents attached 
are confidential and intended solely

for the addressee; it may also be 
privileged. If you receive this e-mail

in error, please notify the sender 
immediately and destroy it.

As its integrity cannot be secured on 
the Internet, the Atos Origin group

liability cannot be triggered for the 
message content. Although the

sender endeavours to maintain a 
computer virus-free network, the sender

does not warrant that this transmission 
is virus-free and will not be

liable for any damages resulting from 
any virus transmitted.

 

On all offers and agreements under 
which Atos Origin supplies goods and/or

services of whatever nature, the Terms 
of Delivery from Atos Origin

exclusively apply. 

The Terms of Delivery shall be promptly 
submitted to you on your request

Reply via email to