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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
