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@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 <[email protected]> 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
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
