[gpfsug-discuss] really slow cnfs vip failover due to exportfs -u in bin/mmnfsfuncs unexportAll and unexportFS

[Sabuj Pattanayek]

yes, it's doing a getaddrinfo() call for every hostname that's a fqdn and
not an ip addr, which we have lots of in our export entries since sometimes
clients update their dns (ip's).

On Thu, Sep 25, 2014 at 8:11 AM, Sabuj Pattanayek <sabujp at gmail.com> wrote:

> our support engineer suggests adding & to the end of the exportfs -u lines
> in the mmnfsfunc script, which is a good workaround, can this be added to
> future gpfs 3.5 and 4.1 rels (haven't even looked at 4.1 yet). I was
> looking at the unexportfs all in nfs-utils/exportfs.c and it looks like the
> limiting factor there would be all the hostname lookups? I don't see what
> exportfs -u is doing other than doing slow reverse lookups and removing the
> export from the nfs stack.
>
> On Thu, Sep 25, 2014 at 7:39 AM, Sabuj Pattanayek <sabujp at gmail.com>
> wrote:
>
>> Hi all,
>>
>> We're running 3.5.0.19 with CNFS and noticed really slow CNFS vip
>> failover times > 4.5mins . It looks like it's being caused by all the
>> exportfs -u calls being made in the unexportAll and the unexportFS function
>> in bin/mmnfsfuncs . What's the purpose of running exportfs -u on all the
>> exported directories? We're running only NFSv3 and have lots of exports and
>> for security reasons can't have one giant NFS export. That may be a
>> possibility with GPFS4.1 and NFSv4 but we won't be migrating to that
>> anytime soon.
>>
>> Assume the network went down for the cnfs server or the system
>> panicked/crashed, what would be the purpose of exportfs -u be in that case,
>> so what's the purpose at all?
>>
>> Thanks,
>> Sabuj
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20140925/1f7cc4cf/attachment-0003.htm>