Re: [gpfsug-discuss] Migration policy confusion

2016-07-07 Thread Daniel Kidger
Mark, For performance reasons, mmdf gets its data updated asynchronously. Did you try waiting a few minutes? Daniel     

Re: [gpfsug-discuss] Migration policy confusion

2016-07-07 Thread mark.b...@siriuscom.com
Thanks all. I realized that my file creation command was building 200k size files instead of the 200MB files. I fixed that and now I see the mmapplypolicy command take a bit more time and show accurate data as well as my bytes are now on the proper NSDs. It’s always some little thing that

Re: [gpfsug-discuss] Migration policy confusion

2016-07-07 Thread mark.b...@siriuscom.com
Thanks Daniel. I did wait for 15-20 minutes after. From: on behalf of Daniel Kidger Reply-To: gpfsug main discussion list Date: Thursday, July 7, 2016 at 8:10 AM To:

Re: [gpfsug-discuss] Migration policy confusion

2016-07-07 Thread mark.b...@siriuscom.com
Olaf, thanks. Yes the plan is to have SSD’s for the system pool ultimately but this is just a test system that I’m using to try and understand teiring better. The files (10 or so of them) are each 200MB in size. Mark From: on behalf of Olaf Weiser

Re: [gpfsug-discuss] Migration policy confusion

2016-07-07 Thread Olaf Weiser
HI , first of all, given by the fact, that the MetaData is stored in system pool .. system should be the "fastest" pool / underlaying disks ... you have.. with a "slow" access to the MD, access to data is very likely  affected.. (except for cached data, where MD is cached) in addition..  tell us,

Re: [gpfsug-discuss] Migration policy confusion

2016-07-07 Thread Marc A Kaplan
At the very least, LOOK at the messages output by the mmapplypolicy command at the beginning and end. The "occupancy" stats for each pool are shown BEFORE and AFTER the command does its work. In even more detail, it shows you how many files and how many KB of data were (or will be or would

Re: [gpfsug-discuss] mmpmon gfis fields question

2016-07-07 Thread Sven Oehme
Hi, this is a undocumented mmpmon call, so you are on your own, but here is the correct description : _n_ IP address of the node responding. This is the address by which GPFS knows the node. _nn_ The name by which GPFS knows the node. _rc_ The reason/error code. In this case, the reply

[gpfsug-discuss] mmpmon gfis fields question

2016-07-07 Thread Aaron Knister
Does anyone know what the fields in the mmpmon gfis output indicate? # socat /var/mmfs/mmpmon/mmpmonSocket - _event_ newconnection _t_ 1467937547 _tu_ 372882 _n_ 10.101.11.1 _node_ local_node mmpmon gfis _response_ begin mmpmon gfis _mmpmon::gfis_ _n_ 10.101.11.1 _nn_ lorej001 _rc_ 0 _t_

Re: [gpfsug-discuss] mmpmon gfis fields question

2016-07-07 Thread Aaron Knister
Ah, thank you! That's a huge help. My preference, of course, would be to use documented calls but I'm already down that rabbit hole calling nsd_ds directly b/c the snmp agent chokes and dies a horrible death with 3.5k nodes and the number of NSDs we have. On 7/7/16 10:16 PM, Sven Oehme wrote: