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>
