Re: REPAIR OCCUPANCY

2023-04-26 Thread Zoltan Forray
Thanks for the reply.  We have run REPAIR OCCUPANCY numerous times now and
it has "adjusted" total reporting occupancy by* -100TB*.  This is very
concerning since our IBM license is storage/TB based and 100TB makes a lot
of difference/required us to increase our license.

On Sat, Apr 22, 2023 at 5:02 AM Josh-Daniel Davis  wrote:

> I mean, it's formally in a whitepaper from 2018,
>
> https://www.ibm.com/support/pages/repair-occupancy-repair-reporting-occupancy-storage-pool
>
> and dsmserv was updated in 2021 to allow this to run on a container pool.
> https://www.ibm.com/support/pages/apar/IT15373
>
> It's not normal maintenance, but for a server that's been around a long
> time, it should be fine to run it.
> Just make sure you're not running expire, replicate, client backups, and
> ideally not a DBB at the same time.
>
> With friendly Regards,
> Josh-Daniel S. Davis
>
>
>
> On Tue, Mar 21, 2023 at 8:01 AM Zoltan Forray  wrote:
>
> > Linux Server 8.1.14.200
> >
> > Looking for feedback on this "undocumented" (i.e. not in a book but
> readily
> > available via Google search) command.
> >
> > We have been seeing lots of wacky occupancy numbers, issues with nodes
> > reporting something in stgpools that are empty, etc.  I stumbled upon
> > REPAIR OCCUPANCY and it has corrected a lot of occupancy reporting
> issues.
> >
> > So far running it against 3-nodes has reduced "reporting occupancy" by
> over
> > 10TB.  This is disconcerting since we do billing via occupancy numbers
> and
> > this will make all of the numbers questionable!
> >
> > My question is, how safe is this command?  Does anyone else run REPAIR
> > OCCUPANCY and if so, how frequently?
> >
> > --
> > *Zoltan Forray*
> > Enterprise Data Protection Administrator
> > VMware Systems Administrator
> > Enterprise Compute & Storage Platforms Team
> > VCU Infrastructure Services
> > zfor...@vcu.edu - 804-828-4807
> > <
> >
> https://www.credly.com/badges/131d9645-79f0-49ec-9f29-41f15900dca7/public_url
> > >
> >
>


-- 
*Zoltan Forray*
Enterprise Data Protection Administrator
VMware Systems Administrator
Enterprise Compute & Storage Platforms Team
VCU Infrastructure Services
zfor...@vcu.edu - 804-828-4807


Re: How to empty a deduped FILE DEVclass stgpool

2023-04-26 Thread Zoltan Forray
Thanks for the reply. We have tried every kind of option/migration/move
nodedata/reclaim/consolidate aggregates/audit stgpool/audit volume, etc, to
no avail.   We are about to go the "nuclear option" and hard delete the
volume!

On Sat, Apr 22, 2023 at 5:01 AM Josh-Daniel Davis  wrote:

> Did you try with both RECONSTRUCT=YES and RECONSTRUCT=NO ?
>
> Sometimes I have had to do that to get stubborn aggregates to move.
>
> Also, what's the reusedelay on the pool?  Sometimes resetting this can
> help.
>
> Lastly, I had a lot of stuck data that wouldn't go away, and 8.1.17.100
> seemed to allow data to be fully purged.  It was cloud containers, which is
> a whole different stack, but who knows.  8.1.17.100 was pretty stable for
> us other than replication storage rules.
>
> Worst case, DEL VOL DISCARDDATA=YES is always a sad option.
>
> With friendly Regards,
> Josh-Daniel S. Davis
>
>
>
> On Wed, Mar 8, 2023 at 9:30 AM Zoltan Forray  wrote:
>
> > We have an old Powervault that is having too many hardware issues
> (5-disks
> > replaced in the past 2-weeks) and are trying to retire it.  It was being
> > used as a low-activity (nextstgpool after offsite copies have been
> > created), deduped FILE DEVclass.
> >
> > We have emptied it down to a few remaining volumes but can not get rid of
> > those last 4-volumes.  We have performed dozens of "move data" (both to a
> > different stgpool and same stgpool) "move nodedata", reclaim stgpool, etc
> > but we always end up with messages like:
> >
> > 3/8/2023 10:19:15 AM ANR3246W Process 28246 skipped 2 files on volume
> > /powervault_pool_2/00061E69.BFS because the files have been *deleted*.
> >
> > and nothing being moved.  Tried marking all volumes as READONLY but the
> > moves simply recreated the existing volumes with the same
> unmovable/deleted
> > objects.
> >
> > We have tried with both reconstructaggregates YES and NO.
> >
> > Occupancy by node shows crazy numbers (currently says this stgpool has a
> > total *5.8TB* occupancy but only 4-partially used 120GB volumes remain).
> >
> > Tried running "restore stgpool preview=yes" with nothing to restore.
> > Tried audit volume fix=no - again with nothing to fix!
> >
> > So what is the magic trick to completely empty this stgpool?
> > --
> > *Zoltan Forray*
> > Enterprise Data Protection Administrator
> > VMware Systems Administrator
> > Enterprise Compute & Storage Platforms Team
> > VCU Infrastructure Services
> > zfor...@vcu.edu - 804-828-4807
> >
>


-- 
*Zoltan Forray*
Enterprise Data Protection Administrator
VMware Systems Administrator
Enterprise Compute & Storage Platforms Team
VCU Infrastructure Services
zfor...@vcu.edu - 804-828-4807