This is a known bug, CR6870042. I'm currently working on a fix for this. jim
On 10/19/09 09:04, Senthil wrote: >Hi All, > >Was trying to understand use of v_rdcnt and v_wrcnt in vnode_t structure for >NFSv4 server >in SXCE_b116 and SXCE_b124. > >Whenever a file (newfile.txt) is copied to a NFSv4 server in b116, the v_wrcnt >and v_rdcnt >used to reflect correct values. When NFSv4 client finishes copying file and >close the file, vnode >counters for newfile.txt on server used to be 0 > >But in b124, even though NFSv4 client closes the file, v_wrcnt for the copied >file on server is still v_wrcnt=1. > >Upon investigation found VOP_CLOSE was not receiving correct "access flags" in >uts/common/fs/nfs/nfs4_srv:8307. > >In function nfs4_srv.c:8200:rfs4_release_share_lock_state, even before >calling VOP_CLOSE >(which actually reduce the v_rdcnt and v_wrcnt), sp->rs_share_access is set >to 0 in >rfs4_unshare (nfs4_srv.c:8274). Since fop_close is not getting correct >"accesss flags", v_wrcnt >is not decremented. > >Was wondering if this a bug or was done with a purpose. Please share your >thoughts. > >Please find the attached dtrace script to be run on NFSv4 server. This script >will display file >access in rfs4_release_share_lock_state and VOP_CLOSE for a particular file. >./nfs.d absolute_file_path_name > >-Thanks > Senthil > > >------------------------------------------------------------------------ > >_______________________________________________ >nfs-discuss mailing list >nfs-discuss at opensolaris.org > >
