It's not something to do with the value of the GID, like being less or greater than some number?
________________________________ From: [email protected] <[email protected]> on behalf of Olaf Weiser <[email protected]> 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 <[email protected]> To: gpfsug main discussion list <[email protected]> Date: 01/19/2017 05:37 PM Subject: Re: [gpfsug-discuss] mmrepquota and group names in GPFS 4.2.2.x Sent by: [email protected] ________________________________ 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 +0000, 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 > <[email protected]<mailto:[email protected]>> 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" > <[email protected]<mailto:[email protected]>> > To: gpfsug main discussion list > <[email protected]<mailto:[email protected]>> > Date: 01/19/2017 04:48 PM > Subject: Re: [gpfsug-discuss] mmrepquota and group names in GPFS > 4.2.2.x > Sent by: > [email protected]<mailto:[email protected]> > ________________________________ > > > > 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 > <[email protected]<mailto:[email protected]>> wrote: > > have you checked, where th fsmgr runs as you have nodes with different code > levels > > mmlsmgr > > > > > From: "Buterbaugh, Kevin L" > <[email protected]<mailto:[email protected]>> > To: gpfsug main discussion list > <[email protected]<mailto:[email protected]>> > Date: 01/18/2017 04:57 PM > Subject: [gpfsug-discuss] mmrepquota and group names in GPFS 4.2.2.x > Sent by: > [email protected]<mailto:[email protected]> > ________________________________ > > > > 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 <fs>” 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 <fs>” 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 > [email protected]<mailto:[email protected]>- > (615)875-9633 > > > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at > spectrumscale.org<http://spectrumscale.org<http://spectrumscale.org/>> > http://gpfsug.org/mailman/listinfo/gpfsug-discuss > > > > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at > spectrumscale.org<http://spectrumscale.org<http://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 -- Lukáš Hejtmánek _______________________________________________ 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
