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 <xami...@gmail.com> 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 <zfor...@vcu.edu> 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 <https://www.credly.com/badges/131d9645-79f0-49ec-9f29-41f15900dca7/public_url>
