Mark,
For performance reasons, mmdf gets its data updated asynchronously.
Did you try waiting a few minutes?
Daniel
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
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:
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
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,
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
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
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_
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: