[gpfsug-discuss] mmapplypolicy didn't migrate everything it should have - why not?

David D. Johnson david_johnson at brown.edu
Tue Apr 18 16:31:12 BST 2017


I have an observation, which may merely serve to show my ignorance:
 Is it significant that the words "EXTERNAL EXEC/script” are seen below?  
If migrating between storage pools within the cluster, I would expect the PIT engine to do the migration.
When doing HSM (off cluster, tape libraries, etc) is where I would expect to need a script to actually do the work.

> [I] 2017-04-18 at 09:06:51.124 Policy execution. 1620263 files dispatched.
> [I] A total of 1620263 files have been migrated, deleted or processed by an EXTERNAL EXEC/script;
>         0 'skipped' files and/or errors.

— ddj
Dave Johnson
Brown University 

> On Apr 18, 2017, at 11:11 AM, Marc A Kaplan <makaplan at us.ibm.com> wrote:
> 
> ANYONE else reading this saga?  Who uses mmapplypolicy to migrate files within multi-TB file systems?  Problems? Or all working as expected?
> 
> ------
> 
> 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.
> 
> 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?
> 
> 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...  
> 
> While we're waiting for that... Here's what I suggest next.
> 
> Add  a clause ...
> 
> SHOW(varchar(KB_ALLOCATED) || ' n=' || varchar(NLINK))
> 
> before the WHERE clause to each of your rules.
> 
> Re-run the command with options  '-I test -L 2'  and collect the output.  
> 
> We're not actually going to move any data, but we're going to look at the files and file sizes that are "chosen"...
> 
> You should see 1.6 million lines that look kind of like this:
> 
> /yy/dat/bigC     RULE 'msx' MIGRATE FROM POOL 'system' TO POOL 'xtra' WEIGHT(inf) SHOW( 1024 n=1)
> 
> 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
> add up to 61TB...  (The show is in KB so the SHOW numbers should add up to 61 billion).
> 
> That sanity checks the policy arithmetic.  Let's assume that's okay. 
> 
> Then the next question is whether the individual numbers are correct... Zach Giles made a suggestion... which I'll interpret as 
> find some of the biggest of those files and check that they really are that big....
> 
> 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...
> and/or they are "illplaced"  - the data blocks aren't all in the pool FROM POOL ...
> 
> 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
> not recognized by mmapplypolicy as sharing storage... 
> This has not come to my attention as a significant problem -- does the file system in question have significant GBs of hard linked files?
> 
> The truth is that you're the first customer/user/admin in a long time to question/examine how mmapplypolicy does its space reckoning ... 
> Optimistically that means it works fine for most customers...  
> 
> So sorry, something unusual about your installation or usage...
> 
> 
> 
> 
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170418/4dd8593c/attachment.htm>


More information about the gpfsug-discuss mailing list