<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 25, 2014 at 7:39 AM, Sabuj Pattanayek <span dir="ltr"><<a href="mailto:sabujp@gmail.com" target="_blank">sabujp@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Thanks,</div><div>Sabuj</div><div><br></div><div><br></div><div><br></div><div><br></div></div>
</blockquote></div><br></div>