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 <[email protected]> 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 <[email protected]> > 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 >> >> >> >> >> >
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at gpfsug.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
