Re: serious volume problem
1999-04-09 15:46:32
Subject: |
Re: serious volume problem |
From: |
Dwight Cook <decook AT AMOCO DOT COM> |
Date: |
Fri, 9 Apr 1999 14:46:32 -0500 |
Oh, this one might be from a problem I'm experiencing...
I have some disk volumes within some storage pools where I went to
remove those volumes from their associated storage pool.
Standard process:
vary offline somevolser
upd volume somevolser acc=reado
vary online somevolser
move data somevolser
(move data process starts & ends with no errors)
del vol somevolser
(return code 13, volume still contains data)
move data somevolser
(0 bytes moved... volume contains no data!)
del vol somevolser
(return code 13, volume still contains data)
audit volume somevolser fix=yes
(volume contains no data!)
del vol somevolser
(return code 13, volume still contains data)
vary offline somevolser
upd vol somevolser acc=destroyed
del vol somevolser discard=yes
(return code 13)
So some ADSM internal still thinks data exists but it don't !
I haven't seen it on any "tape" volumes, only some disk volumes.
Seeing how a reclamation is basically a move data, these are probably
one and the same...
I haven't seen any "lost" data. Currently not very worried... they
probably just exit some loop prior to flip'n some "has data" flag
'cause all the routines to "move data" can't find any, yet data D.N.E.
hence my belief it is just a bum flag value somewhere and not actual
lost data
later,
DWight
______________________________ Reply Separator _________________________________
Subject: Re: serious volume problem
Author: PrathW1 (PrathW1 AT CENTRAL.SSD.JHUAPL DOT EDU) at unix,mime
Date: 4/9/99 10:05 AM
I am confused about this thread.
I just pulled the full text of the APAR from IBM- link.
The APAR TITLE says ADSM is deleteing volumes with files that can't be
reclaimed.
But the "Problem Description" section (keep reading) says the message is
misleading, and all the data was reclaimed.
Can anybody confirm whether we should actually be concerned about missing
data here?
****************************************************************************
***************
IBM text:
Item IX84765
APAR Identifier ...... IX84765 Last Changed..99/02/01 <<...>>
IF A VOLUME CONTAINS FILES WHICH COULD NOT BE RECLAIMED, ADSM
SERVER 3.1.2.0 WILL DELETE THE VOLUME FROM THE STORAGEPOOL.
Symptom ...... IN INCORROUT Status ........... CLOSED PER
Severity ................... 3 Date Closed ......... 99/01/28
Component .......... 576556402 Duplicate of ........
Reported Release ......... 310 Fixed Release ............ 999
Component Name ADSM AIX(V4) SE Special Notice
Current Target Date ..99/02/23 Flags
SCP ................... AIXRSC
Platform ............ AIX
Status Detail: Not Available
PE PTF List:
PTF List:
Release 310 : PTF not available yet
Parent APAR:
Child APAR list:
ERROR DESCRIPTION:
If a volume contains files which could not be reclaimed, ADSM
Server 3.1.2.0 will delete the volume from the storagepool.
Messages from the actlog:
ANR1175W Volume xxxx contains files which could not be reclaimed
ANR1410W Access mode for volume xxxx now set to "unavailable".
ANR1041I Space reclamation ended for volume xxxx.
ANR1341I Scratch volume xxxx has been deleted from storage pool.
LOCAL FIX:
none
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM V3
****************************************************************
* PROBLEM DESCRIPTION: *
ANR1175W Volume xxx contains files which could not be reclaimed
ANR1410W Access mode for volume xxx now set to "unavailable".
ANR1041I Space reclamation ended for volume xxx.
ANR1341I Scratch volume xxx has been deleted from storage pool.
The ANR1175W message is misleading since all of the data was
moved from the volume.
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available.
****************************************************************
Changed the condition causing the message to be a retriable
condition to prevent the message from being issued in those
cases where the message was not necessary.
****************************************************************************
*************************************************
> -----Original Message-----
> From: Henk ten Have [SMTP:hthta AT SARA DOT NL]
> Sent: Friday, April 09, 1999 10:42 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: serious volume problem
>
> On 09-Apr-99 Richard Sims wrote:
> >> 1) If a volume with valid data is deleted from the primary storage
> pool,
> >> how can I get this data back from the copy storage pool?
> >
> > Deletion of files from the primary storage pool means instant expiration
> > for their images in the copy storage pool - gonzo.
>
> Ok, good point. But how can I be sure that those (valid) files did
> really expire their images in the copy storage pool? And that they
> really disappear from the primary pool?
> I mean, how can I check that? Yes, maybe I'm suspicious, but I
> do not always believe what ADSM likes me to believe :-(
>
> >> 2) Is there a consistency check between a primary storage pool and his
> >> copy storage pool?
> >
> > Just Backup Stgpool.
>
> Hm, that's not what I mean: how can I be sure that all data on the
> copy pool is also on the primary pool? (Well, I suppose Backup Stgpool
> will expire data which is found on the copy pool and which is not found
> on the primary pool)
>
> Cheers,
> Henk ten Have.
|
<Prev in Thread] |
Current Thread |
[Next in Thread> |
- Re: serious volume problem, Henk ten Have
- Re: serious volume problem, Henk ten Have
- Re: serious volume problem, Leo Humar
- Re: serious volume problem, Henk ten Have
- Re: serious volume problem, Richard Sims
- Re: serious volume problem, P. Michael Fahey
- Re: serious volume problem, Henk ten Have
- Re: serious volume problem, Richard Sims
- Re: serious volume problem, Prather, Wanda
- Re: serious volume problem,
Dwight Cook <=
|
|
|