<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Am 18.02.16 um 21:57 schrieb Schweiss,
      Chip:<br>
    </div>
    <blockquote
cite="mid:CALeZrrQXDkqSXvQcD_55R2dxypx3Wu5jMaa2+awERX5gHdBXjg@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Thu, Feb 18, 2016 at 5:14 AM,
            Michael Rasmussen <span dir="ltr"><<a
                moz-do-not-send="true" href="mailto:mir@miras.org"
                target="_blank">mir@miras.org</a>></span> wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
                class="">On Thu, 18 Feb 2016 07:13:36 +0100<br>
                Stephan Budach <<a moz-do-not-send="true"
                  href="mailto:stephan.budach@JVM.DE">stephan.budach@JVM.DE</a>>
                wrote:<br>
                <br>
                ><br>
                > So, when I issue a simple ls -l on the folder of
                the vdisks, while the switchover is happening, the
                command somtimes comcludes in 18 to 20 seconds, but
                sometime ls will just sit there for minutes.<br>
                ><br>
              </span>This is a known limitation in NFS. NFS was never
              intended to be<br>
              clustered so what you experience is the NFS process on the
              client side<br>
              keeps kernel locks for the now unavailable NFS server and
              any request<br>
              to the process hangs waiting for these locks to be
              resolved. This can<br>
              be compared to a situation where you hot-swap a drive in
              the pool<br>
              without notifying the pool.<br>
              <br>
              Only way to resolve this is to forcefully kill all NFS
              client processes<br>
              and the restart the NFS client.<br>
              <br>
            </blockquote>
            <div><br>
            </div>
            <div>I've been running RSF-1 on OmniOS since about r151008. 
              All my clients have always been NFSv3 and NFSv4.   <br>
              <br>
              My memory is a bit fuzzy, but when I first started testing
              RSF-1, OmniOS still had the Sun lock manager which was
              later replaced with the BSD lock manager.   This has had
              many difficulties.<br>
              <br>
            </div>
            <div>I do remember that fail overs when I first started with
              RSF-1 never had these stalls, I believe this was because
              the lock state was stored in the pool and the server
              taking over the pool would inherit that state too.   That
              state is now lost when a pool is imported with the BSD
              lock manager.   <br>
              <br>
            </div>
            <div>When I did testing I would do both full speed reading
              and writing to the pool and force fail overs, both by
              command line and by killing power on the active server.   
              Never did I have a fail over take more than about 30
              seconds for NFS to fully resume data flow.   <br>
              <br>
            </div>
            <div>Others who know more about the BSD lock manager vs the
              old Sun lock manager may be able to tell us more.  I'd
              also be curious if Nexenta has addressed this.<br>
              <br>
            </div>
            <div>-Chip<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    I actually don't know, if it's the lock manager or the nfsd itself,
    that caused this, but as I bounced all of them after I failed the
    ZPOOL over while hammering it with reads and writes, lockd would
    also have been part of the processes that had been restarted. And
    remeber, this only happend when failing from to and back one host 
    in a rather quick manner.<br>
    <br>
    Nevertheless, RSF-1 seems to be a solid solution and I will very
    likely implement it across several OmniOS boxes.<br>
    <br>
    Cheers,<br>
    Stephan<br>
  </body>
</html>