<div dir="ltr">I do this for NFSv3 and NFSv4, but all my underlying filesystems are ZFS and that was what prompted me to being setting fsid initially. It may be irrelevant for NFSv3 and/or non-ZFS filesystems.<div><br></div><div>jbh<br><br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 19, 2017 at 9:13 PM Prentice Bisbal <<a href="mailto:pbisbal@pppl.gov">pbisbal@pppl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <p>Even with NFSv3? It seems like fsid=0 is required for NFSv4, but
      does it have any impact on NFSv3? I honestly am not an expert of
      the details of NFS. For me, it's always "just worked", and
      performance was never an issue,  so I never had much reason to dig
      into the details of tweaking/debugging/optimizing NFS.  <br>
    </p></div><div bgcolor="#FFFFFF" text="#000000">
    <pre class="m_445070662492959206moz-signature" cols="72">Prentice </pre></div><div bgcolor="#FFFFFF" text="#000000">
    <div class="m_445070662492959206moz-cite-prefix">On 04/19/2017 02:07 PM, John Hanks
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">I've had far fewer unexplained (although admittedly
        there was a limited search for the guilty) NFS issues since I
        started using fsid= in my NFS exports. If you aren't setting
        that it might be worth a try. NFS seems to be much better at
        recovering from problems with an fsid assigned to the root of
        exports.
        <div><br>
        </div>
        <div>jbh </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr">On Wed, Apr 19, 2017 at 8:58 PM Prentice Bisbal
          <<a href="mailto:pbisbal@pppl.gov" target="_blank">pbisbal@pppl.gov</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here's the
          sequence of events:<br>
          <br>
          1. First job(s) run fine on the node and complete without
          error.<br>
          <br>
          2. Eventually a job fails with a 'permission denied' error
          when it tries<br>
          to access /l/hostname.<br>
          <br>
          Since no jobs fail with a file I/O error, it's hard to confirm
          that the<br>
          jobs themselves are causing the problem. However, if these
          particular<br>
          jobs are the only thing running on the cluster and should be
          the only<br>
          jobs accessing these NFS shares, what else could be causing
          them.<br>
          <br>
          All these systems are getting their user information from
          LDAP. Since<br>
          some jobs run before these errors appear, lack of, or
          inaccurate user<br>
          info doesn't seem to be a likely source of this problem, but
          I'm not<br>
          ruling anything out at this point.<br>
          <br>
          Important detail: This is NFSv3.<br>
          <br>
          Prentice Bisbal<br>
          Lead Software Engineer<br>
          Princeton Plasma Physics Laboratory<br>
          <a href="http://www.pppl.gov" rel="noreferrer" target="_blank">http://www.pppl.gov</a><br>
          <br>
          On 04/19/2017 12:20 PM, Ryan Novosielski wrote:<br>
          > Are you saying they can’t mount the filesystem, or they
          can’t write to a mounted filesystem? Where does this system
          get its user information from, if the latter?<br>
          ><br>
          > --<br>
          > ____<br>
          > || \\UTGERS,         
           |---------------------------*O*---------------------------<br>
          > ||_// the State        |         Ryan Novosielski - <a href="mailto:novosirj@rutgers.edu" target="_blank">novosirj@rutgers.edu</a><br>
          > || \\ University | Sr. Technologist - <a href="tel:%28973%29%20972-0922" value="+19739720922" target="_blank">973/972.0922</a>
          (2x0922) ~*~ RBHS Campus<br>
          > ||  \\    of NJ        | Office of Advanced Research
          Computing - MSB C630, Newark<br>
          >       `'<br>
          ><br>
          >> On Apr 19, 2017, at 12:09, Prentice Bisbal <<a href="mailto:pbisbal@pppl.gov" target="_blank">pbisbal@pppl.gov</a>> wrote:<br>
          >><br>
          >> Beowulfers,<br>
          >><br>
          >> I've been trying to troubleshoot a problem for the
          past two weeks with no luck. We have a cluster here that runs
          only one application (although the details of that application
          change significantly from run-to-run.). Each node in the
          cluster has an NFS export, /local, that can be automounted by
          every other node in the cluster as /l/hostname.<br>
          >><br>
          >> Starting about two weeks ago, when jobs would try to
          access /l/hostname, they would get permission denied messages.
          I tried analyzing this problem by turning on all NFS/RPC
          logging with rpcdebug and also using tcpdump while trying to
          manually mount one of the remote systems. Both approaches
          indicated state file handles were prevent the share from being
          mounted.<br>
          >><br>
          >> Since it has been 6-8 weeks since there were any
          seemingly relevant system config changes, I suspect it's an
          application problem (naturally). On the other hand, the
          application developers/users insist that they haven't made any
          changes, to their code, either. To be honest, there's no
          significant evidence indicating either is at fault. Any
          suggestions on how to debug this and definitively find the
          root cause of these stale file handles?<br>
          >><br>
          >> --<br>
          >> Prentice<br>
          >> _______________________________________________<br>
          >> Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a>
          sponsored by Penguin Computing<br>
          >> To change your subscription (digest mode or
          unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
          <br>
          _______________________________________________<br>
          Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a>
          sponsored by Penguin Computing<br>
          To change your subscription (digest mode or unsubscribe) visit
          <a href="http://www.beowulf.org/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
        </blockquote>
      </div>
      <div dir="ltr">-- <br>
      </div>
      <div data-smartmail="gmail_signature">
        <div dir="ltr">
          <div>‘[A] talent for following the ways of yesterday, is not
            sufficient to improve the world of today.’</div>
          <div> - King Wu-Ling, ruler of the Zhao state in northern
            China, 307 BC</div>
        </div>
      </div>
    </blockquote>
    <br>
  </div></blockquote></div></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div>‘[A] talent for following the ways of yesterday, is not sufficient to improve the world of today.’</div><div> - King Wu-Ling, ruler of the Zhao state in northern China, 307 BC</div></div></div>