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
> <[email protected]> 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 <[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]>
>> To: gpfsug main discussion list <[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]
>>
>>
>>
>> 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] - (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
