[Gluster-devel] semantics about OPEN in NFS

[Niels de Vos]

On Wed, Dec 14, 2016 at 10:28:01AM +0800, jin deng wrote:
> hello,
>     After reading the "nfs" xlator i'm doing some statistics work with
> "debug/io-stats" and find that only the open/create/mkdir will do the "
> *ios_inode_ctx_set*" means other operations such readv(not created during
> the lifetime of this glusterfs process) will not be calculated for the
> throughput and etc.so what's the purpose of only
> set the ctx in open/create/mkdir.

That sound like a bug to me. You should report that through
https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS&component=io-stats

>     By the way,at the mention of "open",this is not a semantics which
> defined by NFS rfc,while I saw many xlator do
> define such a operation but the "nfs" xlator hasn't call any "open"
> operation of subvolumes.I'm wondering when and
> where the open will be called?

Te NFSv3 protocol does not have a OPEN procedure. When an NFSv3 client
wants to read/write a file, the operations are like:

  1. LOOKUP of the filename, returns a filehandle on success
  2. WRITE data with offset in the filehandle

A LOOKUP is like stat(), and the filehandle is a opaque structure that
uniquely identifies the file on the storage backend. A filehandle
basically identifies the filesystem/volume and the inode of the file so
that Gluster/NFS can find it again. For Gluster/NFS the filehandle
consists out of the Volume-ID and the GFID of the file.

Our GlusterFS protocol (for the I/O on the bricks) have support for
procedures that accept a GFID (like a Gluster Volume wide inode). The
Gluster/NFS server uses these procedures exclusively, except for LOOKUP.

HTH,
Niels
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20161214/fe51663e/attachment.sig>