Re: [gpfsug-discuss] mmrepquota and group names in GPFS 4.2.2.x

[Buterbaugh, Kevin L]

Hi All,

Let me try to answer some questions that have been raised by various list 
members…

1.  I am not using nscd.
2.  getent group with either a GID or a group name resolves GID’s / names that 
are being printed as GIDs by mmrepquota
3.  The GID’s in question are all in a normal range … i.e. some group names 
that are being printed by mmrepquota have GIDs “close” to others that are being 
printed as GID’s
4.  strace’ing mmrepquota doesn’t show anything relating to nscd or anything 
that jumps out at me

Here’s another point … I am 95% sure that I have a client that was running 
4.2.1.1 and mmrepquota displayed the group names … I then upgraded GPFS on it … 
no other changes … and now it’s mostly GID’s.  I’m not 100% sure because output 
scrolled out of my terminal buffer.

Thanks to all for the suggestions … please feel free to keep them coming.  To 
any of the GPFS team on this mailing list, at least one other person has 
reported the same behavior … is this a known bug?

Kevin

On Jan 19, 2017, at 3:22 PM, 
greg.lehm...@csiro.au wrote:


It's not something to do with the value of the GID, like being less or greater 
than some number?


From: 
gpfsug-discuss-boun...@spectrumscale.org
 
>
 on behalf of Olaf Weiser 
>
Sent: Friday, 20 January 2017 3:16 AM
To: gpfsug main discussion list
Subject: Re: [gpfsug-discuss] mmrepquota and group names in GPFS 4.2.2.x

in my eyes.. that's the hint .. not to wait until all 700 clients 'll have been 
updated .. before open PMR .. ;-) ...



From:Lukas Hejtmanek >
To:gpfsug main discussion list 
>
Date:01/19/2017 05:37 PM
Subject:Re: [gpfsug-discuss] mmrepquota and group names in GPFS 4.2.2.x
Sent by:
gpfsug-discuss-boun...@spectrumscale.org




Just leting know, I see the same problem with 4.2.2.1 version. mmrepquota
resolves only some of group names.

On Thu, Jan 19, 2017 at 04:25:20PM +, Buterbaugh, Kevin L wrote:
> Hi Olaf,
>
> We will continue upgrading clients in a rolling fashion, but with ~700 of 
> them, it’ll be a few weeks.  And to me that’s good … I don’t consider 
> figuring out why this is happening a waste of time and therefore having 
> systems on both versions is a good thing.
>
> While I would prefer not to paste actual group names and GIDs into this 
> public forum, I can assure you that on every 4.2.1.1 system that I have tried 
> this on:
>
> 1.  mmrepquota reports mostly GIDs, only a few group names
> 2.  /etc/nsswitch.conf says to look at files first
> 3.  the GID is in /etc/group
> 4.  length of group name doesn’t matter
>
> I have a support contract with IBM, so I can open a PMR if necessary.  I just 
> thought someone on the list might have an idea as to what is happening or be 
> able to point out the obvious explanation that I’m missing.  ;-)
>
> Thanks…
>
> Kevin
>
> On Jan 19, 2017, at 10:05 AM, Olaf Weiser 
> >
>  wrote:
>
> unfortunately , I don't own a cluster right now, which has 4.2.2 to double 
> check... SpectrumScale should resolve the GID into a name, if it find the 
> name somewhere...
>
> but in your case.. I would say.. before we waste to much time in a 
> version-mismatch issue.. finish the rolling migration, especially RHEL .. and 
> then we continue
> meanwhile  -I'll try to find a way for me here to setup up an 4.2.2. cluster
> cheers
>
>
>
> From:"Buterbaugh, Kevin L" 
> >
> To:gpfsug main discussion list 
> >
> Date:01/19/2017 04:48 PM
> Subject:Re: [gpfsug-discuss] mmrepquota and group names in GPFS 
> 4.2.2.x
> Sent by:
> gpfsug-discuss-boun...@spectrumscale.org
> 
>
>
>
> Hi Olaf,
>
> The filesystem manager runs on one of our servers, all of which are upgraded 
> to 4.2.2.x.
>
> Also, I didn’t mention this yesterday but our /etc/nsswitch.conf has “files” 
> listed first for /etc/group.
>
> In addition to a mixture of GPFS versions, we also have a mixture of OS 
> versions (RHEL 6/7).  AFAIK tell with all of my testing / experimenting the 
> only factor that seems to change the behavior of mmrepquota in regards to 
> GIDs versus group names is the 

Re: [gpfsug-discuss] Bad performance with GPFS system monitoring (mmsysmon) in GPFS 4.2.1.1

[Simon Thompson (Research Computing - IT Services)]

On some of our nodes we were regularly seeing procees hung timeouts in dmesg 
from a python process, which I vaguely thought was related to the monitoring 
process (though we have other python bits from openstack running on these 
boxes). These are all running 4.2.2.0 code

Simon

From: gpfsug-discuss-boun...@spectrumscale.org 
[gpfsug-discuss-boun...@spectrumscale.org] on behalf of Mathias Dietz 
[mdi...@de.ibm.com]
Sent: 19 January 2017 18:07
To: FC; gpfsug main discussion list
Subject: Re: [gpfsug-discuss] Bad performance with GPFS system monitoring 
(mmsysmon) in GPFS 4.2.1.1

Hi Farid,

there is no official way for disabling the system health monitoring because 
other components rely on it (e.g. GUI, CES, Install Toolkit,..)
If you are fine with the consequences you can just delete the 
mmsysmonitor.conf, which will prevent the monitor from starting.

During our testing we did not see a significant performance impact caused by 
the monitoring.
In 4.2.2 some component monitors (e.g. disk) have been further improved to 
reduce polling and use notifications instead.

Nevertheless, I would like to better understand what the issue is.
What kind of workload do you run ?
Do you see spikes in CPU usage every 30 seconds ?
Is it the same on all cluster nodes or just on some of them ?
Could you send us the output of "mmhealth node show -v" to see which monitors 
are active.

It might make sense to open a PMR to get this issue fixed.

Thanks.


Mit freundlichen Grüßen / Kind regards

Mathias Dietz

Spectrum Scale - Release Lead Architect (4.2.X Release)
System Health and Problem Determination Architect
IBM Certified Software Engineer

--
IBM Deutschland
Hechtsheimer Str. 2
55131 Mainz
Mobile: +49-15152801035
E-Mail: mdi...@de.ibm.com
--
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Koederitz, Geschäftsführung: Dirk 
Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 
243294





From:FC 
To:"gpfsug-discuss@spectrumscale.org" 
Date:01/19/2017 07:06 AM
Subject:[gpfsug-discuss] Bad performance with GPFS system monitoring 
(mmsysmon) in GPFS 4.2.1.1
Sent by:gpfsug-discuss-boun...@spectrumscale.org




Hi all,

We are facing performance issues with some of our applications due to the GPFS 
system monitoring (mmsysmon) on CentOS 7.2.

Bad performances (increase of iteration time) are seen every 30s exactly as the 
occurence frequency of mmsysmon ; the default monitor interval set to 30s in 
/var/mmfs/mmsysmon/mmsysmonitor.conf

Shutting down GPFS with mmshutdown doesnt stop this process, we stopped it with 
the command mmsysmoncontrol and we get a stable iteration time.

What are the impacts of disabling this process except losing access to mmhealth 
commands ?
Do you have an idea of a proper way to disable it for good without doing it in 
rc.local or increasing the monitoring interval in the configuration file ?

Thanks,
Farid ___
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

Re: [gpfsug-discuss] Bad performance with GPFS system monitoring (mmsysmon) in GPFS 4.2.1.1

[Mathias Dietz]

Hi Farid,

there is no official way for disabling the system health monitoring 
because other components rely on it (e.g. GUI, CES, Install Toolkit,..) 
If you are fine with the consequences you can just delete the 
mmsysmonitor.conf, which will prevent the monitor from starting.

During our testing we did not see a significant performance impact caused 
by the monitoring. 
In 4.2.2 some component monitors (e.g. disk) have been further improved to 
reduce polling and use notifications instead. 

Nevertheless, I would like to better understand what the issue is. 
What kind of workload do you run ? 
Do you see spikes in CPU usage every 30 seconds ? 
Is it the same on all cluster nodes or just on some of them ?
Could you send us the output of "mmhealth node show -v" to see which 
monitors are active. 

It might make sense to open a PMR to get this issue fixed. 

Thanks. 


Mit freundlichen Grüßen / Kind regards

Mathias Dietz

Spectrum Scale - Release Lead Architect (4.2.X Release)
System Health and Problem Determination Architect 
IBM Certified Software Engineer

--
IBM Deutschland
Hechtsheimer Str. 2
55131 Mainz
Mobile: +49-15152801035
E-Mail: mdi...@de.ibm.com
--
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Koederitz, Geschäftsführung: Dirk 
Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, 
HRB 243294
 




From:   FC 
To: "gpfsug-discuss@spectrumscale.org" 

Date:   01/19/2017 07:06 AM
Subject:[gpfsug-discuss] Bad performance with GPFS system 
monitoring (mmsysmon) in GPFS 4.2.1.1
Sent by:gpfsug-discuss-boun...@spectrumscale.org



Hi all,

We are facing performance issues with some of our applications due to the 
GPFS system monitoring (mmsysmon) on CentOS 7.2.

Bad performances (increase of iteration time) are seen every 30s exactly 
as the occurence frequency of mmsysmon ; the default monitor interval set 
to 30s in /var/mmfs/mmsysmon/mmsysmonitor.conf 

Shutting down GPFS with mmshutdown doesnt stop this process, we stopped it 
with the command mmsysmoncontrol and we get a stable iteration time.

What are the impacts of disabling this process except losing access to 
mmhealth commands ? 
Do you have an idea of a proper way to disable it for good without doing 
it in rc.local or increasing the monitoring interval in the configuration 
file ?

Thanks,
Farid ___
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

Re: [gpfsug-discuss] mmrepquota and group names in GPFS 4.2.2.x

[Peter Serocka]

Any caching in effect? Like nscd which is configured separately in 
/etc/nscd.conf

Any insights from strace’ing mmrepquota?

For example, when a plain ls -l doesn’t look groups up in /etc/group
but queries from nscd instead, strace output has something like:

connect(4, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = 0
sendto(4, "\2\0\0\0\f\0\0\0\6\0\0\0group\0", 18, MSG_NOSIGNAL, NULL, 0) = 18

— Peter

> On 2017 Jan 19 Thu, at 23:46, Buterbaugh, Kevin L 
>  wrote:
> 
> Hi Olaf,
> 
> The filesystem manager runs on one of our servers, all of which are upgraded 
> to 4.2.2.x.
> 
> Also, I didn’t mention this yesterday but our /etc/nsswitch.conf has “files” 
> listed first for /etc/group.
> 
> In addition to a mixture of GPFS versions, we also have a mixture of OS 
> versions (RHEL 6/7).  AFAIK tell with all of my testing / experimenting the 
> only factor that seems to change the behavior of mmrepquota in regards to 
> GIDs versus group names is the GPFS version.
> 
> Other ideas, anyone?  Is anyone else in a similar situation and can test 
> whether they see similar behavior?
> 
> Thanks...
> 
> Kevin
> 
>> On Jan 19, 2017, at 2:45 AM, Olaf Weiser  wrote:
>> 
>> have you checked, where th fsmgr runs as you have nodes with different code 
>> levels
>> 
>> mmlsmgr 
>> 
>> 
>> 
>> 
>> From:"Buterbaugh, Kevin L" 
>> To:gpfsug main discussion list 
>> Date:01/18/2017 04:57 PM
>> Subject:[gpfsug-discuss] mmrepquota and group names in GPFS 4.2.2.x
>> Sent by:gpfsug-discuss-boun...@spectrumscale.org
>> 
>> 
>> 
>> Hi All, 
>> 
>> We recently upgraded our cluster (well, the servers are all upgraded; the 
>> clients are still in progress) from GPFS 4.2.1.1 to GPFS 4.2.2.1 and there 
>> appears to be a change in how mmrepquota handles group names in its’ output. 
>>  I’m trying to get a handle on it, because it is messing with some of my 
>> scripts and - more importantly - because I don’t understand the behavior.
>> 
>> From one of my clients which is still running GPFS 4.2.1.1 I can run an 
>> “mmrepquota -g ” and if the group exists in /etc/group the group name is 
>> displayed.  Of course, if the group doesn’t exist in /etc/group, the GID is 
>> displayed.  Makes sense.
>> 
>> However, on my servers which have been upgraded to GPFS 4.2.2.1 most - but 
>> not all - of the time I see GID numbers instead of group names.  My question 
>> is, what is the criteria GPFS 4.2.2.x is using to decide when to display a 
>> GID instead of a group name?  It’s apparently *not* the length of the name 
>> of the group, because I have output in front of me where a 13 character long 
>> group name is displayed but a 7 character long group name is *not* displayed 
>> - its’ GID is instead (and yes, both exist in /etc/group).
>> 
>> I know that sample output would be useful to illustrate this, but I do not 
>> want to post group names or GIDs to a public mailing list … if you want to 
>> know what those are, you’ll have to ask Vladimir Putin… ;-)
>> 
>> I am in the process of updating scripts to use “mmrepquota -gn ” and 
>> then looking up the group name myself, but I want to try to understand this. 
>>  Thanks…
>> 
>> Kevin
> 
> 
> —
> Kevin Buterbaugh - Senior System Administrator
> Vanderbilt University - Advanced Computing Center for Research and Education
> kevin.buterba...@vanderbilt.edu - (615)875-9633
> 
> 
> 
> ___
> 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

Re: [gpfsug-discuss] mmrepquota and group names in GPFS 4.2.2.x

[Lukas Hejtmanek]

Just leting know, I see the same problem with 4.2.2.1 version. mmrepquota
resolves only some of group names.

On Thu, Jan 19, 2017 at 04:25:20PM +, Buterbaugh, Kevin L wrote:
> Hi Olaf,
> 
> We will continue upgrading clients in a rolling fashion, but with ~700 of 
> them, it’ll be a few weeks.  And to me that’s good … I don’t consider 
> figuring out why this is happening a waste of time and therefore having 
> systems on both versions is a good thing.
> 
> While I would prefer not to paste actual group names and GIDs into this 
> public forum, I can assure you that on every 4.2.1.1 system that I have tried 
> this on:
> 
> 1.  mmrepquota reports mostly GIDs, only a few group names
> 2.  /etc/nsswitch.conf says to look at files first
> 3.  the GID is in /etc/group
> 4.  length of group name doesn’t matter
> 
> I have a support contract with IBM, so I can open a PMR if necessary.  I just 
> thought someone on the list might have an idea as to what is happening or be 
> able to point out the obvious explanation that I’m missing.  ;-)
> 
> Thanks…
> 
> Kevin
> 
> On Jan 19, 2017, at 10:05 AM, Olaf Weiser 
> > wrote:
> 
> unfortunately , I don't own a cluster right now, which has 4.2.2 to double 
> check... SpectrumScale should resolve the GID into a name, if it find the 
> name somewhere...
> 
> but in your case.. I would say.. before we waste to much time in a 
> version-mismatch issue.. finish the rolling migration, especially RHEL .. and 
> then we continue
> meanwhile  -I'll try to find a way for me here to setup up an 4.2.2. cluster
> cheers
> 
> 
> 
> From:"Buterbaugh, Kevin L" 
> >
> To:gpfsug main discussion list 
> >
> Date:01/19/2017 04:48 PM
> Subject:Re: [gpfsug-discuss] mmrepquota and group names in GPFS 
> 4.2.2.x
> Sent by:
> gpfsug-discuss-boun...@spectrumscale.org
> 
> 
> 
> 
> Hi Olaf,
> 
> The filesystem manager runs on one of our servers, all of which are upgraded 
> to 4.2.2.x.
> 
> Also, I didn’t mention this yesterday but our /etc/nsswitch.conf has “files” 
> listed first for /etc/group.
> 
> In addition to a mixture of GPFS versions, we also have a mixture of OS 
> versions (RHEL 6/7).  AFAIK tell with all of my testing / experimenting the 
> only factor that seems to change the behavior of mmrepquota in regards to 
> GIDs versus group names is the GPFS version.
> 
> Other ideas, anyone?  Is anyone else in a similar situation and can test 
> whether they see similar behavior?
> 
> Thanks...
> 
> Kevin
> 
> On Jan 19, 2017, at 2:45 AM, Olaf Weiser 
> > wrote:
> 
> have you checked, where th fsmgr runs as you have nodes with different code 
> levels
> 
> mmlsmgr
> 
> 
> 
> 
> From:"Buterbaugh, Kevin L" 
> >
> To:gpfsug main discussion list 
> >
> Date:01/18/2017 04:57 PM
> Subject:[gpfsug-discuss] mmrepquota and group names in GPFS 4.2.2.x
> Sent by:
> gpfsug-discuss-boun...@spectrumscale.org
> 
> 
> 
> 
> Hi All,
> 
> We recently upgraded our cluster (well, the servers are all upgraded; the 
> clients are still in progress) from GPFS 4.2.1.1 to GPFS 4.2.2.1 and there 
> appears to be a change in how mmrepquota handles group names in its’ output.  
> I’m trying to get a handle on it, because it is messing with some of my 
> scripts and - more importantly - because I don’t understand the behavior.
> 
> From one of my clients which is still running GPFS 4.2.1.1 I can run an 
> “mmrepquota -g ” and if the group exists in /etc/group the group name is 
> displayed.  Of course, if the group doesn’t exist in /etc/group, the GID is 
> displayed.  Makes sense.
> 
> However, on my servers which have been upgraded to GPFS 4.2.2.1 most - but 
> not all - of the time I see GID numbers instead of group names.  My question 
> is, what is the criteria GPFS 4.2.2.x is using to decide when to display a 
> GID instead of a group name?  It’s apparently *not* the length of the name of 
> the group, because I have output in front of me where a 13 character long 
> group name is displayed but a 7 character long group name is *not* displayed 
> - its’ GID is instead (and yes, both exist in /etc/group).
> 
> I know that sample output would be useful to illustrate this, but I do not 
> want to post group names or GIDs to a public mailing list … if you want to 
> know what those are, you’ll have to ask Vladimir Putin… ;-)
> 
> I am in the process of updating scripts to use 

Re: [gpfsug-discuss] mmrepquota and group names in GPFS 4.2.2.x

[Buterbaugh, Kevin L]

Hi Olaf,

We will continue upgrading clients in a rolling fashion, but with ~700 of them, 
it’ll be a few weeks.  And to me that’s good … I don’t consider figuring out 
why this is happening a waste of time and therefore having systems on both 
versions is a good thing.

While I would prefer not to paste actual group names and GIDs into this public 
forum, I can assure you that on every 4.2.1.1 system that I have tried this on:

1.  mmrepquota reports mostly GIDs, only a few group names
2.  /etc/nsswitch.conf says to look at files first
3.  the GID is in /etc/group
4.  length of group name doesn’t matter

I have a support contract with IBM, so I can open a PMR if necessary.  I just 
thought someone on the list might have an idea as to what is happening or be 
able to point out the obvious explanation that I’m missing.  ;-)

Thanks…

Kevin

On Jan 19, 2017, at 10:05 AM, Olaf Weiser 
> wrote:

unfortunately , I don't own a cluster right now, which has 4.2.2 to double 
check... SpectrumScale should resolve the GID into a name, if it find the name 
somewhere...

but in your case.. I would say.. before we waste to much time in a 
version-mismatch issue.. finish the rolling migration, especially RHEL .. and 
then we continue
meanwhile  -I'll try to find a way for me here to setup up an 4.2.2. cluster
cheers



From:"Buterbaugh, Kevin L" 
>
To:gpfsug main discussion list 
>
Date:01/19/2017 04:48 PM
Subject:Re: [gpfsug-discuss] mmrepquota and group names in GPFS 4.2.2.x
Sent by:
gpfsug-discuss-boun...@spectrumscale.org




Hi Olaf,

The filesystem manager runs on one of our servers, all of which are upgraded to 
4.2.2.x.

Also, I didn’t mention this yesterday but our /etc/nsswitch.conf has “files” 
listed first for /etc/group.

In addition to a mixture of GPFS versions, we also have a mixture of OS 
versions (RHEL 6/7).  AFAIK tell with all of my testing / experimenting the 
only factor that seems to change the behavior of mmrepquota in regards to GIDs 
versus group names is the GPFS version.

Other ideas, anyone?  Is anyone else in a similar situation and can test 
whether they see similar behavior?

Thanks...

Kevin

On Jan 19, 2017, at 2:45 AM, Olaf Weiser 
> wrote:

have you checked, where th fsmgr runs as you have nodes with different code 
levels

mmlsmgr




From:"Buterbaugh, Kevin L" 
>
To:gpfsug main discussion list 
>
Date:01/18/2017 04:57 PM
Subject:[gpfsug-discuss] mmrepquota and group names in GPFS 4.2.2.x
Sent by:
gpfsug-discuss-boun...@spectrumscale.org




Hi All,

We recently upgraded our cluster (well, the servers are all upgraded; the 
clients are still in progress) from GPFS 4.2.1.1 to GPFS 4.2.2.1 and there 
appears to be a change in how mmrepquota handles group names in its’ output.  
I’m trying to get a handle on it, because it is messing with some of my scripts 
and - more importantly - because I don’t understand the behavior.

From one of my clients which is still running GPFS 4.2.1.1 I can run an 
“mmrepquota -g ” and if the group exists in /etc/group the group name is 
displayed.  Of course, if the group doesn’t exist in /etc/group, the GID is 
displayed.  Makes sense.

However, on my servers which have been upgraded to GPFS 4.2.2.1 most - but not 
all - of the time I see GID numbers instead of group names.  My question is, 
what is the criteria GPFS 4.2.2.x is using to decide when to display a GID 
instead of a group name?  It’s apparently *not* the length of the name of the 
group, because I have output in front of me where a 13 character long group 
name is displayed but a 7 character long group name is *not* displayed - its’ 
GID is instead (and yes, both exist in /etc/group).

I know that sample output would be useful to illustrate this, but I do not want 
to post group names or GIDs to a public mailing list … if you want to know what 
those are, you’ll have to ask Vladimir Putin… ;-)

I am in the process of updating scripts to use “mmrepquota -gn ” and then 
looking up the group name myself, but I want to try to understand this.  Thanks…

Kevin


—
Kevin Buterbaugh - Senior System Administrator
Vanderbilt University - Advanced Computing Center for Research and Education
kevin.buterba...@vanderbilt.edu- 
(615)875-9633


___
gpfsug-discuss mailing list
gpfsug-discuss at 

Re: [gpfsug-discuss] mmrepquota and group names in GPFS 4.2.2.x

[Olaf Weiser]

unfortunately , I don't own a cluster right
now, which has 4.2.2 to double check... SpectrumScale should resolve the
GID into a name, if it find the name somewhere... but in your case.. I would say.. before
we waste to much time in a version-mismatch issue.. finish the rolling
migration, especially RHEL .. and then we continue meanwhile  -I'll try to find a
way for me here to setup up an 4.2.2. clustercheersFrom:      
 "Buterbaugh, Kevin
L" To:      
 gpfsug main discussion
list Date:      
 01/19/2017 04:48 PMSubject:    
   Re: [gpfsug-discuss]
mmrepquota and group names in GPFS 4.2.2.xSent by:    
   gpfsug-discuss-boun...@spectrumscale.orgHi Olaf, The filesystem manager runs on one of our servers, all
of which are upgraded to 4.2.2.x.Also, I didn’t mention this yesterday but our /etc/nsswitch.conf
has “files” listed first for /etc/group.In addition to a mixture of GPFS versions, we also have
a mixture of OS versions (RHEL 6/7).  AFAIK tell with all of my testing
/ experimenting the only factor that seems to change the behavior of mmrepquota
in regards to GIDs versus group names is the GPFS version.Other ideas, anyone?  Is anyone else in a similar
situation and can test whether they see similar behavior?Thanks...KevinOn Jan 19, 2017, at 2:45 AM, Olaf Weiser 
wrote:have you checked, where th fsmgr runs
as you have nodes with different code levelsmmlsmgr From:        "Buterbaugh,
Kevin L" To:        gpfsug
main discussion list Date:        01/18/2017
04:57 PMSubject:        [gpfsug-discuss]
mmrepquota and group names in GPFS 4.2.2.xSent by:        gpfsug-discuss-boun...@spectrumscale.orgHi All, We recently upgraded our cluster (well, the servers are all upgraded; the
clients are still in progress) from GPFS 4.2.1.1 to GPFS 4.2.2.1 and there
appears to be a change in how mmrepquota handles group names in its’ output.
 I’m trying to get a handle on it, because it is messing with some
of my scripts and - more importantly - because I don’t understand the
behavior.From one of my clients which is still running GPFS 4.2.1.1 I can run an
“mmrepquota -g ” and if the group exists in /etc/group the
group name is displayed.  Of course, if the group doesn’t exist in
/etc/group, the GID is displayed.  Makes sense.However, on my servers which have been upgraded to GPFS 4.2.2.1 most -
but not all - of the time I see GID numbers instead of group names.  My
question is, what is the criteria GPFS 4.2.2.x is using to decide when
to display a GID instead of a group name?  It’s apparently *not*
the length of the name of the group, because I have output in front of
me where a 13 character long group name is displayed but a 7 character
long group name is *not* displayed - its’ GID is instead (and yes, both
exist in /etc/group).I know that sample output would be useful to illustrate this, but I do
not want to post group names or GIDs to a public mailing list … if you
want to know what those are, you’ll have to ask Vladimir Putin… ;-)I am in the process of updating scripts to use “mmrepquota -gn ”
and then looking up the group name myself, but I want to try to understand
this.  Thanks…Kevin—Kevin Buterbaugh - Senior System AdministratorVanderbilt University - Advanced Computing Center for
Research and Educationkevin.buterba...@vanderbilt.edu- (615)875-9633___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss

___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss

Re: [gpfsug-discuss] mmrepquota and group names in GPFS 4.2.2.x

[Buterbaugh, Kevin L]

Hi Olaf,

The filesystem manager runs on one of our servers, all of which are upgraded to 
4.2.2.x.

Also, I didn’t mention this yesterday but our /etc/nsswitch.conf has “files” 
listed first for /etc/group.

In addition to a mixture of GPFS versions, we also have a mixture of OS 
versions (RHEL 6/7).  AFAIK tell with all of my testing / experimenting the 
only factor that seems to change the behavior of mmrepquota in regards to GIDs 
versus group names is the GPFS version.

Other ideas, anyone?  Is anyone else in a similar situation and can test 
whether they see similar behavior?

Thanks...

Kevin

On Jan 19, 2017, at 2:45 AM, Olaf Weiser 
> wrote:

have you checked, where th fsmgr runs as you have nodes with different code 
levels

mmlsmgr




From:"Buterbaugh, Kevin L" 
>
To:gpfsug main discussion list 
>
Date:01/18/2017 04:57 PM
Subject:[gpfsug-discuss] mmrepquota and group names in GPFS 4.2.2.x
Sent by:
gpfsug-discuss-boun...@spectrumscale.org




Hi All,

We recently upgraded our cluster (well, the servers are all upgraded; the 
clients are still in progress) from GPFS 4.2.1.1 to GPFS 4.2.2.1 and there 
appears to be a change in how mmrepquota handles group names in its’ output.  
I’m trying to get a handle on it, because it is messing with some of my scripts 
and - more importantly - because I don’t understand the behavior.

From one of my clients which is still running GPFS 4.2.1.1 I can run an 
“mmrepquota -g ” and if the group exists in /etc/group the group name is 
displayed.  Of course, if the group doesn’t exist in /etc/group, the GID is 
displayed.  Makes sense.

However, on my servers which have been upgraded to GPFS 4.2.2.1 most - but not 
all - of the time I see GID numbers instead of group names.  My question is, 
what is the criteria GPFS 4.2.2.x is using to decide when to display a GID 
instead of a group name?  It’s apparently *not* the length of the name of the 
group, because I have output in front of me where a 13 character long group 
name is displayed but a 7 character long group name is *not* displayed - its’ 
GID is instead (and yes, both exist in /etc/group).

I know that sample output would be useful to illustrate this, but I do not want 
to post group names or GIDs to a public mailing list … if you want to know what 
those are, you’ll have to ask Vladimir Putin… ;-)

I am in the process of updating scripts to use “mmrepquota -gn ” and then 
looking up the group name myself, but I want to try to understand this.  Thanks…

Kevin


—
Kevin Buterbaugh - Senior System Administrator
Vanderbilt University - Advanced Computing Center for Research and Education
kevin.buterba...@vanderbilt.edu - 
(615)875-9633



___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss

Re: [gpfsug-discuss] mmrepquota and group names in GPFS 4.2.2.x

[Olaf Weiser]

have you checked, where th fsmgr runs as
you have nodes with different code levelsmmlsmgr From:      
 "Buterbaugh, Kevin
L" To:      
 gpfsug main discussion
list Date:      
 01/18/2017 04:57 PMSubject:    
   [gpfsug-discuss]
mmrepquota and group names in GPFS 4.2.2.xSent by:    
   gpfsug-discuss-boun...@spectrumscale.orgHi All, We recently upgraded our cluster (well, the servers are
all upgraded; the clients are still in progress) from GPFS 4.2.1.1 to GPFS
4.2.2.1 and there appears to be a change in how mmrepquota handles group
names in its’ output.  I’m trying to get a handle on it, because
it is messing with some of my scripts and - more importantly - because
I don’t understand the behavior.From one of my clients which is still running GPFS 4.2.1.1
I can run an “mmrepquota -g ” and if the group exists in /etc/group
the group name is displayed.  Of course, if the group doesn’t exist
in /etc/group, the GID is displayed.  Makes sense.However, on my servers which have been upgraded to GPFS
4.2.2.1 most - but not all - of the time I see GID numbers instead of group
names.  My question is, what is the criteria GPFS 4.2.2.x is using
to decide when to display a GID instead of a group name?  It’s apparently
*not* the length of the name of the group, because I have output in front
of me where a 13 character long group name is displayed but a 7 character
long group name is *not* displayed - its’ GID is instead (and yes, both
exist in /etc/group).I know that sample output would be useful to illustrate
this, but I do not want to post group names or GIDs to a public mailing
list … if you want to know what those are, you’ll have to ask Vladimir
Putin… ;-)I am in the process of updating scripts to use “mmrepquota
-gn ” and then looking up the group name myself, but I want
to try to understand this.  Thanks…Kevin—Kevin Buterbaugh - Senior System AdministratorVanderbilt University - Advanced Computing Center for
Research and Educationkevin.buterba...@vanderbilt.edu- (615)875-9633___gpfsug-discuss mailing listgpfsug-discuss at spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss

___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss