Completely normal, working as designed. We do this on purpose. Depending on how 
you set the migration and reclamation thresholds, that first FILE storage pool 
will be internally reclaimed before any migration starts. That reclamation 
process will be labeled "Migration". (This has tripped me up on a Dark And 
Stormy Night when something broke and I had to figure it out, until I realized, 
"I did this".)

To stop this, set the first stgpool to have RECLAIM=100. An alternative is to 
set RECLAIMSTGPOOL to be your second storage pool (the Dell Powervault), though 
in that case these reclamation processes will still be called Migration.

Roger Deschner
University of Illinois at Chicago
"I have not lost my mind. It is backed up on tape somewhere"

________________________________________
From: Zoltan Forray <zfor...@vcu.edu>
Sent: Tuesday, November 15, 2022 18:04
Subject: Odd incident with stgpool nextpool/migration

ISP RHEL Linux 8.1.14.200

We just had an odd incident occur and question if this a "feature", "new
restriction" or a "bug".

We have a primary disk stgpool (regular FILE DEVCLASS no DEDUPE) with a
NEXTPOOL to an NFS mount stgpool (also regular FILE DEVCLASS no DEDUPE).
The disk pool was filling faster than it could migrate.

We recently resurrected an old 200TB Dell Powervault attached to this
server (regular FILE DEVCLASS WITH DEDUPE and NEXTPOOL is tape) and as an
"emergency" measure, decided to change the disk stgpool NEXTPOOL to point
to the Powervault.

Instead of redirecting migration to the Powervault, the migration tasks are
migrating BACK INTO the disk stgpool itself, which is at 90%

Process Number: 2,451
Process Description: Migration
Process Status: Volume */tsmpool01/00059802.BFS* (storage pool TSMSTG),
[snippage for brevity] Current input volume: */tsmpool01/00059802.BFS.*
Current output volume(s): */tsmpool01/0005A027.BFS.*

While I realize that technically this is called "Reclamation",
#1 - it is odd that the process is still being called MIGRATION
#2 - it isn't doing what we said - migrate data to another stgpool - not
the same one that has the issue/shortage?

Is this a new restriction that you can't NEXTPOOL from a NON-dedupe to a
DEDUPE stgpool?  Or have we found a bug?
--
*Zoltan Forray*
Enterprise Backup Administrator
VMware Systems Administrator
Enterprise Compute & Storage Platforms Team
VCU Infrastructure Services
www.ucc.vcu.edu
zfor...@vcu.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://phishing.vcu.edu/
<https://adminmicro2.questionpro.com>

Reply via email to