<font size=2 face="sans-serif">ANYONE else reading this saga? Who
uses mmapplypolicy to migrate files within multi-TB file systems? Problems?
Or all working as expected?</font><br><br><font size=2 face="sans-serif">------</font><br><br><font size=2 face="sans-serif">Well, again mmapplypolicy "thinks"
it has "chosen" 1.6 million files whose total size is 61 Terabytes
and migrating those will bring the occupancy of gpfs23capacity pool to
98% and then we're done.</font><br><br><font size=2 face="sans-serif">So now I'm wondering where this is going
wrong. Is there some bug in the reckoning inside of mmapplypolicy
or somewhere else in GPFS?</font><br><br><font size=2 face="sans-serif">Sure you can put in an PMR, and probably
should. I'm guessing whoever picks up the PMR will end up calling
or emailing me ... but maybe she can do some of the clerical work for us...
</font><br><br><font size=2 face="sans-serif">While we're waiting for that... Here's
what I suggest next.</font><br><br><font size=2 face="sans-serif">Add a clause ...</font><br><br><font size=2 face="sans-serif">SHOW(varchar(KB_ALLOCATED) || ' n='
|| varchar(NLINK))</font><br><br><font size=2 face="sans-serif">before the WHERE clause to each of your
rules.</font><br><br><font size=2 face="sans-serif">Re-run the command with options '-I
test -L 2' and collect the output. </font><br><br><font size=2 face="sans-serif">We're not actually going to move any
data, but we're going to look at the files and file sizes that are "chosen"...</font><br><br><font size=2 face="sans-serif">You should see 1.6 million lines that
look kind of like this:</font><br><br><font size=2 face="sans-serif">/yy/dat/bigC RULE 'msx'
MIGRATE FROM POOL 'system' TO POOL 'xtra' WEIGHT(inf) SHOW( 1024 n=1)</font><br><br><font size=2 face="sans-serif">Run a script over the output to add
up all the SHOW() values in the lines that contain TO POOL 'gpfs23capacity'
and verify that they do indeed</font><br><font size=2 face="sans-serif">add up to 61TB... (The show is
in KB so the SHOW numbers should add up to 61 billion).<br></font><br><font size=2 face="sans-serif">That sanity checks the policy arithmetic.
Let's assume that's okay. </font><br><br><font size=2 face="sans-serif">Then the next question is whether the
individual numbers are correct... Zach Giles made a suggestion... which
I'll interpret as <br>find some of the biggest of those files and check that they really are
that big....</font><br><br><font size=2 face="sans-serif">At this point, I really don't know,
but I'm guessing there's some discrepances in the reported KB_ALLOCATED
numbers for many of the files...</font><br><font size=2 face="sans-serif">and/or they are "illplaced"
- the data blocks aren't all in the pool FROM POOL ...</font><br><br><font size=2 face="sans-serif">HMMMM.... I just thought about
this some more and added the NLINK statistic. It would be unusual
for this to be a big problem, but files that are hard linked are<br>not recognized by mmapplypolicy as sharing storage... <br>This has not come to my attention as a significant problem -- does the
file system in question have significant GBs of hard linked files?</font><br><br><font size=2 face="sans-serif">The truth is that you're the first customer/user/admin
in a long time to question/examine how mmapplypolicy does its space reckoning
... <br>Optimistically that means it works fine for most customers... </font><br><br><font size=2 face="sans-serif">So sorry, something unusual about your
installation or usage...</font><br><br><font size=2 face="sans-serif"><br></font><br><BR>