<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: nfsstat in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/nfsstat/m-p/2899351#M104615</link>
    <description>No Sir &lt;BR /&gt;&lt;BR /&gt;NFS V2 doest not mean that it is always TCP based. nfsd daemon will listen to both UDP and TCP port number 2049.&lt;BR /&gt;&lt;BR /&gt;The protocol for communication can be actually selected by the NFS client with -o option in mount command.&lt;BR /&gt;&lt;BR /&gt;eg:-&lt;BR /&gt;&lt;BR /&gt;mount -o proto=tcp ... ... .. &lt;BR /&gt;&lt;BR /&gt;mount -o proto=udp ... ... ...&lt;BR /&gt;&lt;BR /&gt;regards,&lt;BR /&gt;&lt;BR /&gt;U.SivaKumar&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
    <pubDate>Fri, 07 Feb 2003 11:47:27 GMT</pubDate>
    <dc:creator>U.SivaKumar_2</dc:creator>
    <dc:date>2003-02-07T11:47:27Z</dc:date>
    <item>
      <title>nfsstat</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/nfsstat/m-p/2899345#M104609</link>
      <description>Hi at all,&lt;BR /&gt;&lt;BR /&gt;could anyone explain me the meaning of dupchecks and dupreqs in the output of nfsstat -s and what is to do if both values &lt;BR /&gt;are very high?&lt;BR /&gt;&lt;BR /&gt;What is the different of connection oriented and connectionless oriented rpc servers ?&lt;BR /&gt;&lt;BR /&gt;Kind regards ...&lt;BR /&gt;Claus</description>
      <pubDate>Fri, 07 Feb 2003 10:06:39 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/nfsstat/m-p/2899345#M104609</guid>
      <dc:creator>Rammig Claus</dc:creator>
      <dc:date>2003-02-07T10:06:39Z</dc:date>
    </item>
    <item>
      <title>Re: nfsstat</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/nfsstat/m-p/2899346#M104610</link>
      <description>Hi&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;read&lt;BR /&gt;&lt;BR /&gt;&lt;A href="http://www.docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B1031-90048/B1031-90048_top.html&amp;amp;con=/hpux/onlinedocs/B1031-90048/00/00/45-con.html&amp;amp;toc=/hpux/onlinedocs/B1031-90048/00/00/45-toc.html&amp;amp;searchterms=nfsstat&amp;amp;queryid=20030207-030915" target="_blank"&gt;http://www.docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B1031-90048/B1031-90048_top.html&amp;amp;con=/hpux/onlinedocs/B1031-90048/00/00/45-con.html&amp;amp;toc=/hpux/onlinedocs/B1031-90048/00/00/45-toc.html&amp;amp;searchterms=nfsstat&amp;amp;queryid=20030207-030915&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;and&lt;BR /&gt;&lt;BR /&gt;&lt;A href="http://www.docs.hp.com/hpux/onlinedocs/1435/NFSPerformanceTuninginHP-UX11.0and11iSystems.pdf" target="_blank"&gt;http://www.docs.hp.com/hpux/onlinedocs/1435/NFSPerformanceTuninginHP-UX11.0and11iSystems.pdf&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;and&lt;BR /&gt;&lt;A href="http://publib16.boulder.ibm.com/pseries/en_US/aixbman/prftungd/2365ca2.htm" target="_blank"&gt;http://publib16.boulder.ibm.com/pseries/en_US/aixbman/prftungd/2365ca2.htm&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;dupchecks &lt;BR /&gt;Number of RPC calls looked up in the duplicate request cache &lt;BR /&gt;dupreqs &lt;BR /&gt;Number of duplicate RPC calls found &lt;BR /&gt;from webopaedia&lt;BR /&gt;&lt;BR /&gt;connectionless Last modified: Friday, June 07, 2002   &lt;BR /&gt; &lt;BR /&gt;&lt;BR /&gt;  &lt;BR /&gt;Refers to network protocols in which a host can send a message without establishing a connection with the recipient. That is, the host simply puts the message onto the network with the destination address and hopes that it arrives. Examples of connectionless protocols include Ethernet, IPX, and UDP. &lt;BR /&gt;In contrast, connection-oriented protocols require a channel to be established between the sender and receiver before any messages are transmitted. &lt;BR /&gt; &lt;BR /&gt;                Steve Steel&lt;BR /&gt;</description>
      <pubDate>Fri, 07 Feb 2003 10:31:06 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/nfsstat/m-p/2899346#M104610</guid>
      <dc:creator>Steve Steel</dc:creator>
      <dc:date>2003-02-07T10:31:06Z</dc:date>
    </item>
    <item>
      <title>Re: nfsstat</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/nfsstat/m-p/2899347#M104611</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;dupchecks &lt;BR /&gt;Number of RPC calls looked up in the duplicate request cache &lt;BR /&gt;&lt;BR /&gt;dupreqs &lt;BR /&gt;Number of duplicate RPC calls found &lt;BR /&gt;The output also displays a count of the various kinds of calls and their respective percentages. &lt;BR /&gt;&lt;BR /&gt;Duplicate checks are performed for operations that cannot be performed twice with the same result. The classic example is the rm command. The first rm command will succeed, but if the reply is lost, the client will retransmit it. We want duplicate requests like these to succeed, so the duplicate cache is consulted, and if it is a duplicate request, the same (successful) result is returned on the duplicate request as was generated on the initial request. &lt;BR /&gt;&lt;BR /&gt;Conection oriented NFS uses TCP protocol .&lt;BR /&gt;Connectionless NFS uses UDP protocol.&lt;BR /&gt;&lt;BR /&gt;regards,&lt;BR /&gt;U.SivaKumar&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Fri, 07 Feb 2003 10:38:22 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/nfsstat/m-p/2899347#M104611</guid>
      <dc:creator>U.SivaKumar_2</dc:creator>
      <dc:date>2003-02-07T10:38:22Z</dc:date>
    </item>
    <item>
      <title>Re: nfsstat</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/nfsstat/m-p/2899348#M104612</link>
      <description>Hi Steve,&lt;BR /&gt;&lt;BR /&gt;does that mean, &lt;BR /&gt;- that connection oriented rpc servers handle the communication over TCP and not over UDP?&lt;BR /&gt;- the communication has its own socket by connection oriented?&lt;BR /&gt;&lt;BR /&gt;And at all what is a duplicate request cache?&lt;BR /&gt;&lt;BR /&gt;Kind regards ...&lt;BR /&gt;Claus&lt;BR /&gt;</description>
      <pubDate>Fri, 07 Feb 2003 10:50:37 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/nfsstat/m-p/2899348#M104612</guid>
      <dc:creator>Rammig Claus</dc:creator>
      <dc:date>2003-02-07T10:50:37Z</dc:date>
    </item>
    <item>
      <title>Re: nfsstat</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/nfsstat/m-p/2899349#M104613</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;connection oriented NFS uses only TCP a connection orineted protocol.&lt;BR /&gt;&lt;BR /&gt;Ref:&lt;BR /&gt;&lt;BR /&gt; Duplicate request cache&lt;BR /&gt;&lt;BR /&gt;   The typical NFS version 3 protocol failure recovery model&lt;BR /&gt;   uses client time-out and retry to handle server crashes,&lt;BR /&gt;   network partitions, and lost server replies. A retried&lt;BR /&gt;   request is called a duplicate of the original.&lt;BR /&gt;&lt;BR /&gt;   When used in a file server context, the term idempotent can&lt;BR /&gt;   be used to distinguish between operation types. An idempotent&lt;BR /&gt;   request is one that a server can perform more than once with&lt;BR /&gt;   equivalent results (though it may in fact change, as a side&lt;BR /&gt;   effect, the access time on a file, say for READ). Some NFS&lt;BR /&gt;   operations are obviously non-idempotent. They cannot be&lt;BR /&gt;   reprocessed without special attention simply because they may&lt;BR /&gt;   fail if tried a second time. The CREATE request, for example,&lt;BR /&gt;   can be used to create a file for which the owner does not&lt;BR /&gt;   have write permission. A duplicate of this request cannot&lt;BR /&gt;   succeed if the original succeeded. Likewise, a file can be&lt;BR /&gt;   removed only once.&lt;BR /&gt;&lt;BR /&gt;   The side effects caused by performing a duplicate&lt;BR /&gt;   non-idempotent request can be destructive (for example, a&lt;BR /&gt;   truncate operation causing lost writes). The combination of a&lt;BR /&gt;   stateless design with the common choice of an unreliable&lt;BR /&gt;   network transport (UDP) implies the possibility of&lt;BR /&gt;   destructive replays of non-idempotent requests. Though to be&lt;BR /&gt;   more accurate, it is the inherent stateless design of the NFS&lt;BR /&gt;   version 3 protocol on top of an unreliable RPC mechanism that&lt;BR /&gt;   yields the possibility of destructive replays of&lt;BR /&gt;   non-idempotent requests, since even in an implementation of&lt;BR /&gt;   the NFS version 3 protocol over a reliable&lt;BR /&gt;   connection-oriented transport, a connection break with&lt;BR /&gt;   automatic reestablishment requires duplicate request&lt;BR /&gt;   processing (the client will retransmit the request, and the&lt;BR /&gt;   server needs to deal with a potential duplicate&lt;BR /&gt;   non-idempotent request).&lt;BR /&gt;&lt;BR /&gt;   Most NFS version 3 protocol server implementations use a&lt;BR /&gt;   cache of recent requests (called the duplicate request cache)&lt;BR /&gt;   for the processing of duplicate non-idempotent requests. The&lt;BR /&gt;   duplicate request cache provides a short-term memory&lt;BR /&gt;   mechanism in which the original completion status of a&lt;BR /&gt;   request is remembered and the operation attempted only once.&lt;BR /&gt;   If a duplicate copy of this request is received, then the&lt;BR /&gt;   original completion status is returned.&lt;BR /&gt;&lt;BR /&gt;   The duplicate-request cache mechanism has been useful in&lt;BR /&gt;   reducing destructive side effects caused by duplicate NFS&lt;BR /&gt;   version 3 protocol requests. This mechanism, however, does&lt;BR /&gt;   not guarantee against these destructive side effects in all&lt;BR /&gt;   failure modes. Most servers store the duplicate request cache&lt;BR /&gt;   in RAM, so the contents are lost if the server crashes.  The&lt;BR /&gt;   exception to this may possibly occur in a redundant server&lt;BR /&gt;   approach to high availability, where the file system itself&lt;BR /&gt;   may be used to share the duplicate request cache state. Even&lt;BR /&gt;   if the cache survives server reboots (or failovers in the&lt;BR /&gt;   high availability case), its effectiveness is a function of&lt;BR /&gt;   its size. A network partition can cause a cache entry to be&lt;BR /&gt;   reused before a client receives a reply for the corresponding&lt;BR /&gt;   request. If this happens, the duplicate request will be&lt;BR /&gt;   processed as a new one, possibly with destructive side&lt;BR /&gt;   effects.&lt;BR /&gt;&lt;BR /&gt;regards,&lt;BR /&gt;&lt;BR /&gt;U.SivaKumar&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Fri, 07 Feb 2003 11:00:52 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/nfsstat/m-p/2899349#M104613</guid>
      <dc:creator>U.SivaKumar_2</dc:creator>
      <dc:date>2003-02-07T11:00:52Z</dc:date>
    </item>
    <item>
      <title>Re: nfsstat</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/nfsstat/m-p/2899350#M104614</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;could it be when we are using NFS Vers.2 on HPUX 11i that the connection is always tcp-based?&lt;BR /&gt;&lt;BR /&gt;Best regards ...&lt;BR /&gt;Claus</description>
      <pubDate>Fri, 07 Feb 2003 11:23:53 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/nfsstat/m-p/2899350#M104614</guid>
      <dc:creator>Rammig Claus</dc:creator>
      <dc:date>2003-02-07T11:23:53Z</dc:date>
    </item>
    <item>
      <title>Re: nfsstat</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/nfsstat/m-p/2899351#M104615</link>
      <description>No Sir &lt;BR /&gt;&lt;BR /&gt;NFS V2 doest not mean that it is always TCP based. nfsd daemon will listen to both UDP and TCP port number 2049.&lt;BR /&gt;&lt;BR /&gt;The protocol for communication can be actually selected by the NFS client with -o option in mount command.&lt;BR /&gt;&lt;BR /&gt;eg:-&lt;BR /&gt;&lt;BR /&gt;mount -o proto=tcp ... ... .. &lt;BR /&gt;&lt;BR /&gt;mount -o proto=udp ... ... ...&lt;BR /&gt;&lt;BR /&gt;regards,&lt;BR /&gt;&lt;BR /&gt;U.SivaKumar&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Fri, 07 Feb 2003 11:47:27 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/nfsstat/m-p/2899351#M104615</guid>
      <dc:creator>U.SivaKumar_2</dc:creator>
      <dc:date>2003-02-07T11:47:27Z</dc:date>
    </item>
    <item>
      <title>Re: nfsstat</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/nfsstat/m-p/2899352#M104616</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;we have two nfs-server on different machines.&lt;BR /&gt;Both use autofs.&lt;BR /&gt;The only difference is, that in the auto.direct from the first nfsserver we use nfs vers. 2 on HPUX 11i and from the second we use vers. 3 on HPUX 11.0.&lt;BR /&gt;&lt;BR /&gt;Nfsstat shows on first nfsserver connections oriented and on the second connectionsless oriented communications. &lt;BR /&gt;In both cases there is no use of any protocol relatet mountoption.&lt;BR /&gt;&lt;BR /&gt;Could you explain this?&lt;BR /&gt;&lt;BR /&gt;Best regards ...&lt;BR /&gt;Claus</description>
      <pubDate>Fri, 07 Feb 2003 13:09:07 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/nfsstat/m-p/2899352#M104616</guid>
      <dc:creator>Rammig Claus</dc:creator>
      <dc:date>2003-02-07T13:09:07Z</dc:date>
    </item>
  </channel>
</rss>

