I did searched the NLM request patterns, 71 16.254082000 10.209.192.99 -> 10.209.106.175 NFS 220 V3 READDIR Call, FH:0xc07c5f3e 72 16.274974000 10.209.106.175 -> 10.209.192.99 NFS 504 V3 READDIR Reply (Call In 71) . .. 1 bigfileset file1.txt file1 win prof linux_perf1 myperf 75 16.300651000 10.209.192.99 -> 10.209.106.175 NFS 224 V3 READDIRPLUS Call, FH:0xc07c5f3e 77 16.300899000 10.209.106.175 -> 10.209.192.99 NFS 644 V3 READDIRPLUS Reply (Call In 75) . .. 1 bigfileset file1.txt file1 win prof linux_perf1 myperf 83 16.329492000 10.209.192.99 -> 10.209.106.175 NFS 220 V3 READDIR Call, FH:0x2bba9473 84 16.329789000 10.209.106.175 -> 10.209.192.99 NFS 276 V3 READDIR Reply (Call In 83) . .. 2 89 16.344960000 10.209.192.99 -> 10.209.106.175 NFS 220 V3 READDIR Call, FH:0x3443e0a4 90 16.346297000 10.209.106.175 -> 10.209.192.99 NFS 344 V3 READDIR Reply (Call In 89) . .. 00000003 00000002 00000001 101 18.707363000 10.209.192.99 -> 10.209.106.175 NFS 220 V3 READDIR Call, FH:0x68999248 102 18.707918000 10.209.106.175 -> 10.209.192.99 NFS 312 V3 READDIR Reply (Call In 101) . .. file.txt f2.txt 103 18.891133000 10.209.192.99 -> 10.209.106.175 NFS 224 V3 READDIRPLUS Call, FH:0x68999248 104 18.891410000 10.209.106.175 -> 10.209.192.99 NFS 952 V3 READDIRPLUS Reply (Call In 103) . .. file.txt f2.txt 106 20.855574000 10.209.192.99 -> 10.209.106.175 NLM 240 V4 SHARE Call FH:0x02158c1b 107 20.855790000 10.209.106.175 -> 10.209.192.99 NLM 96 V4 SHARE Reply (Call In 106) 108 20.858447000 10.209.192.99 -> 10.209.106.175 NLM 240 V4 UNSHARE Call FH:0x02158c1b 109 20.858564000 10.209.106.175 -> 10.209.192.99 NLM 96 V4 UNSHARE Reply (Call In 108) 110 20.864414000 10.209.192.99 -> 10.209.106.175 NFS 212 V3 READ Call, FH:0x02158c1b Offset:0 Len:4096 111 20.864627000 10.209.106.175 -> 10.209.192.99 NFS 224 V3 READ Reply (Call In 110) Len:33 112 20.864939000 10.209.192.99 -> 10.209.106.175 NFS 212 V3 READ Call, FH:0x02158c1b Offset:33 Len:4063 113 20.865144000 10.209.106.175 -> 10.209.192.99 NFS 188 V3 READ Reply (Call In 112) Len:0 175 25.087178000 10.209.192.99 -> 10.209.106.175 NLM 240 V4 SHARE Call FH:0x02158c1b 176 25.087454000 10.209.106.175 -> 10.209.192.99 NLM 96 V4 SHARE Reply (Call In 175) 177 25.087783000 10.209.192.99 -> 10.209.106.175 NFS 256 V3 WRITE Call, FH:0x02158c1b Offset:0 Len:35 FILE_SYNC 178 25.087960000 10.209.106.175 -> 10.209.192.99 NFS 96 V3 WRITE Reply (Call In 177) Error:NFS3ERR_PERM <<< This got retuned because of state_share_check_conflict
181 27.230913000 10.209.192.99 -> 10.209.106.175 NLM 240 V4 UNSHARE Call FH:0x02158c1b 182 27.231161000 10.209.106.175 -> 10.209.192.99 NLM 96 V4 UNSHARE Reply (Call In 181) 183 27.366762000 10.209.192.99 -> 10.209.106.175 NFS 224 V3 READDIRPLUS Call, FH:0x68999248 184 27.367036000 10.209.106.175 -> 10.209.192.99 NFS 952 V3 READDIRPLUS Reply (Call In 183) . .. file.txt f2.txt 187 32.834297000 10.209.192.99 -> 10.209.106.175 NLM 240 V4 SHARE Call FH:0x02158c1b 188 32.842137000 10.209.106.175 -> 10.209.192.99 NLM 96 V4 SHARE Reply (Call In 187) NLM_DENIED After NFS3ERR_PERM, SHARE calls also get conflict. In nfs3_write, 220 /* An actual write is to be made, prepare it */ 221 222 res->res_write3.status = nfs3_Errno_state( 223 state_share_anonymous_io_start( 224 entry, 225 OPEN4_SHARE_ACCESS_WRITE, 226 SHARE_BYPASS_V3_WRITE)); I am not sure but, This will fail because previous SHARE call has already asked ACCESS_WRITE, Right? I did compile 'next' with VFS, but exports are not getting loaded it gives following error, vfs_lookup_path :FSAL :CRIT :Could not get handle for path /home/tushar/export, error Function not implemented the base filesystem is ext4 with kerenl 3.18.30 Currently working VXFS fsal is built with 2.2.0 version, And it will take time to port it on next or 2.3. Looks like first I need move to next version of ganesha. Tushar. On Mon, Apr 11, 2016 at 9:02 PM, Frank Filz <ffilz...@mindspring.com> wrote: > >> Code branch - Ganesha 2.2.0-stable >> >> On windows 2008 R2 nfsv3 mount, when I try to save file it fails with >> NLM_DENIED, On windows it show error "The process cannot access the file >> because another process has locked a portion of the file". >> while this message, I saw nlm4_Share --> state_nlm_share --> >> state_share_check_conflict fails with error, "deny write denied by > existing >> access write" and returns 'conflict' >> >> I wonder should there be check for same owner in >> state_share_check_conflict, If same owner is requesting write should it >> result in conflict? >> >> There is no other process on windows machine, other than current open >> notepad session for given file. >> >> Any one know reason/patch for this behavior. > > Could you try again with 2.4 on FSAL_VFS? > > Unfortunately I don't have a Windows client to test, and Windows is the only > NFS v3 client I know of that uses NLM_SHARE. I would love to understand it's > usage pattern because the NLM spec is not clear on how NLM_SHARE should > behave if the owner already has a share. There is no documentation of share > upgrade/downgrade semantics. > > Thanks > > Frank > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
