I already considered that. The tape pool is defined at 1500-scratch and
only 920-are used:
11:22:33 AM PROCESSOR : show sspool
-> Pool ARCHIVEPOOL(2): Strategy=10, ClassId=0, ClassName=DISK,
Next=6, ReclaimPool=0, HighMig=90, LowMig=70, MigProcess=1,
Access=0,
MaxSize=0, Cache=0, Collocate=0, Reclaim=60, MaxScratch=0,
ReuseDelay=0, crcData=False, verifyData=True,
ReclaimProcess=1, OffsiteReclaimLimit=NoLimit, ReclamationType=0
Index=0, OpenCount=0, CreatePending=False, DeletePending=False
CopyPoolCount=0, CopyPoolIdList=, CopyContinue=Yes
deduplicate=False, identifyProcess=1
Shreddable=False, shredCount=0
AutoCopy=Client, Encrypted=0, Compression=0
DS Extension: VolListSize=16, VolCount=1, VolLast=0
-> Pool BACKUPPOOL(1): Strategy=10, ClassId=0, ClassName=DISK,
Next=6, ReclaimPool=0, HighMig=95, LowMig=90, MigProcess=2,
Access=0,
MaxSize=0, Cache=0, Collocate=0, Reclaim=60, MaxScratch=0,
ReuseDelay=0, crcData=False, verifyData=True,
ReclaimProcess=1, OffsiteReclaimLimit=NoLimit, ReclamationType=0
Index=1, OpenCount=0, CreatePending=False, DeletePending=False
CopyPoolCount=0, CopyPoolIdList=, CopyContinue=Yes
deduplicate=False, identifyProcess=1
Shreddable=False, shredCount=0
AutoCopy=Client, Encrypted=0, Compression=0
DS Extension: VolListSize=24, VolCount=18, VolLast=2
-> Pool COPYPOOL-OFFSITE(-2): Strategy=30, ClassId=4,
ClassName=IBM3494-SUN,
Next=0, ReclaimPool=0, HighMig=90, LowMig=70, MigProcess=1,
Access=0,
MaxSize=0, Cache=0, Collocate=0, Reclaim=66, MaxScratch=1500,
ReuseDelay=0, crcData=False, verifyData=True,
ReclaimProcess=1, OffsiteReclaimLimit=NoLimit, ReclamationType=0
Index=2, OpenCount=0, CreatePending=False, DeletePending=False
CopyPoolCount=0, CopyPoolIdList=, CopyContinue=Yes
deduplicate=False, identifyProcess=0
Shreddable=False, shredCount=0
AutoCopy=Client, Encrypted=0, Compression=0
AS Extension: NumDefVols=770, NumEmptyVols=0,
NumScratchVols=770, NumRsvdScratch=0
-> Pool PRIMARY-ONSITE(6): Strategy=30, ClassId=3, ClassName=IBM3494,
Next=0, ReclaimPool=0, HighMig=90, LowMig=70, MigProcess=1,
Access=0,
MaxSize=0, Cache=0, Collocate=0, Reclaim=63, MaxScratch=1500,
ReuseDelay=0, crcData=False, verifyData=True,
ReclaimProcess=1, OffsiteReclaimLimit=NoLimit, ReclamationType=0
Index=3, OpenCount=0, CreatePending=False, DeletePending=False
CopyPoolCount=0, CopyPoolIdList=, CopyContinue=Yes
deduplicate=False, identifyProcess=1
Shreddable=False, shredCount=0
AutoCopy=Client, Encrypted=0, Compression=0
AS Extension: NumDefVols=920, NumEmptyVols=0,
NumScratchVols=920, NumRsvdScratch=0
On Tue, Jul 18, 2017 at 11:11 AM, Loon, Eric van (ITOPT3) - KLM <
Eric-van.Loon AT klm DOT com> wrote:
> Hi Zoltan!
> Try this one: issue a "show sspool" command. If the sum of NumScratchVols
> and NumRsvdScratch equals your total amount of scratch tapes, you're
> probably hit by this APAR: http://www-01.ibm.com/support/
> docview.wss?uid=swg1IC77685
> I have bine there, either raise your maxscratch value or bounce the server
> to reset the NumRsvdScratch value. Although the APAR is old and states it's
> fixed in 6.2, I still get hit by it on my 6.3 servers. I raised the
> maxscratch to 100,000 to get rid of it. These reserved scratches are (in my
> case) mainly caused by failed storage agent scratch mounts.
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Zoltan Forray
> Sent: dinsdag 18 juli 2017 14:49
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: No space available in storage pool failure but there is plenty of
> space
>
> TSM Linux server 7.1.6.3. Client is Linux 7.1.6.4.
>
> This morning at 6am is the second time I have had this "failure" when it
> isn't true.
>
> ANR0522W Transaction failed for session 19482 for node
> VCU-GS1.CHPC.VCU.EDU (Linux x86-64) - no space available in storage pool
> BACKUPPOOL and all successor pools.
>
> But it isn't true. The BACKUPPOOL pool is only 92% used (of 9TB) and the
> hi/low triggers are 95/90. I checked activity logs and there haven't been
> any recent migrations.
>
> The NEXTPOOL is tape and all 9-drives are free and the MAXSCRATCH count
> hasn't been hit.
>
> The backup only transferred 60GB (of 108TB examined) before dying due to
> this erroneous error.
>
> No other errors in the activity log. So, what gives?
>
> --
> *Zoltan Forray*
> Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon
> Monitor Administrator VMware Administrator Virginia Commonwealth University
> UCC/Office of Technology Services www.ucc.vcu.edu zforray AT vcu DOT edu -
> 804-828-4807 Don't be a phishing victim - VCU and other reputable
> organizations will never use email to request that you reply with your
> password, social security number or confidential personal information. For
> more details visit http://infosecurity.vcu.edu/phishing.html
> ********************************************************
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> ********************************************************
>
--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html
|
