<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Te NFSv3 protocol does not have a OPEN procedure. When an NFSv3 client<br>
wants to read/write a file, the operations are like:<br>
<br>
  1. LOOKUP of the filename, returns a filehandle on success<br>
  2. WRITE data with offset in the filehandle<br>
<br>
A LOOKUP is like stat(), and the filehandle is a opaque structure that<br>
uniquely identifies the file on the storage backend. A filehandle<br>
basically identifies the filesystem/volume and the inode of the file so<br>
that Gluster/NFS can find it again. For Gluster/NFS the filehandle<br>
consists out of the Volume-ID and the GFID of the file.<br>
<br>
Our GlusterFS protocol (for the I/O on the bricks) have support for<br>
procedures that accept a GFID (like a Gluster Volume wide inode). The<br>
Gluster/NFS server uses these procedures exclusively, except for LOOKUP.<br></blockquote><div><br></div><div> Thanks for your explain,Niels.I know  the operations which you mentioned.While my confusion is</div><div><br></div><div>that why the xlators such as &quot;debug/io-stats&quot; defines a &quot;open&quot; procedure if the NFSv3 protocol doesn&#39;t</div><div><br></div><div>require it.And when will these procedures be called? I haven&#39;t found any caller in the code of &quot;server/nfs&quot;. Any</div><div><br></div><div>other top xlator will call that?</div><br><br>-- <br><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><span style="font-family:&quot;Helvetica Neue&quot;,Helvetica,Arial,sans-serif;font-size:15px">Sincerely</span>,<div>DengJin</div></div></div></div></div><br>