nfs4 mounting

[Saurabh Sehgal]

Yes, I do open the file exactly where you mentioned it ... ( sorry forgot to
put in that detail ),  after locking the lock file, I tried it with just 2
machines right now, and the 2 processes were able to successfully write to
the file, however, with 3 machines, there is a very wierd deadlock, and the
process just hangs, and eventually times out ....

I ran this with the nfsd_debug on ... and got the following output :

**** a close on the bin file right here *****
Oct  2 14:59:37 amdha01 kernel: NFSD: nfsd4_close on file file.sys
Oct  2 14:59:37 amdha01 kernel: NFSD: preprocess_seqid_op: seqid=5636
stateid = (4701c40e/00006a2d/00003b08/00000000)
Oct  2 14:59:37 amdha01 kernel: NFSD: find_stateid flags 0x45

###################################################################################################################

Right after this point, there is an unending series of fh_verify, compound,
dispatch calls

Oct  2 14:59:37 amdha01 kernel: renewing client (clientid 4701c40e/00000017)
Oct  2 14:59:37 amdha01 kernel: nfsv4 compound op #3: 9
Oct  2 14:59:37 amdha01 kernel: nfsd: fh_verify(16: 01010001 00000000
001c358a f34a917b 00000000 00000000)
Oct  2 14:59:37 amdha01 kernel: nfsd: fh_verify - just checking
Oct  2 14:59:37 amdha01 kernel: nfsd_dispatch: vers 4 proc 1
Oct  2 14:59:37 amdha01 kernel: nfsv4 compound op #1: 22
Oct  2 14:59:37 amdha01 kernel: nfsd: fh_verify(16: 01010001 00000000
0001ff01 f34a9042 00000000 00000000)
Oct  2 14:59:37 amdha01 kernel: nfsv4 compound op #2: 3
Oct  2 14:59:37 amdha01 kernel: nfsd: fh_verify(16: 01010001 00000000
0001ff01 f34a9042 00000000 00000000)
Oct  2 14:59:37 amdha01 kernel: nfsd: fh_verify - just checking
Oct  2 14:59:37 amdha01 kernel: nfsd_dispatch: vers 4 proc 1
Oct  2 14:59:37 amdha01 kernel: nfsv4 compound op #1: 22
Oct  2 14:59:37 amdha01 kernel: nfsd: fh_verify(16: 01010001 00000000
0001ff01 f34a9042 00000000 00000000)
Oct  2 14:59:37 amdha01 kernel: nfsv4 compound op #2: 9
Oct  2 14:59:37 amdha01 kernel: nfsd: fh_verify(16: 01010001 00000000
0001ff01 f34a9042 00000000 00000000)
Oct  2 14:59:37 amdha01 kernel: nfsd: fh_verify - just checking
Oct  2 14:59:37 amdha01 kernel: nfsd_dispatch: vers 4 proc 1
Oct  2 14:59:37 amdha01 kernel: nfsv4 compound op #1: 22
Oct  2 14:59:37 amdha01 kernel: nfsd: fh_verify(16: 01010001 00000000
001bb23c 6d47c9c9 00000000 00000000)
Oct  2 14:59:37 amdha01 kernel: nfsv4 compound op #2: 9
Oct  2 14:59:37 amdha01 kernel: nfsd: fh_verify(16: 01010001 00000000
001bb23c 6d47c9c9 00000000 00000000)
Oct  2 14:59:37 amdha01 kernel: nfsd: fh_verify - just checking
Oct  2 14:59:37 amdha01 kernel: nfsd_dispatch: vers 4 proc 1
Oct  2 14:59:37 amdha01 kernel: nfsv4 compound op #1: 22
Oct  2 14:59:37 amdha01 kernel: nfsd: fh_verify(16: 01010001 00000000
001bb23c 6d47c9c9 00000000 00000000)

............

Also, is there anyway that I can run an strace on nfsd ? I tried but I get
the following error :

strace -p 22345 -o trace.out
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted

Can you please let me know if there is something else I need to do for the
strace to work ?

Thank you,

Saurabh







On 10/2/07, Trond Myklebust <trond.myklebust at fys.uio.no> wrote:
>
> On Tue, 2007-10-02 at 11:19 -0400, Saurabh Sehgal wrote:
> > Hi,
> >
> > I was able to get some more information on what is really going on ...
> > the file that we are trying to write to over nfs is a binary file ...
> > we do not obtain the lock on the file we need to write to, but obtain
> > it on a completely diff file. Once this "lock file" is obtained, the
> > record is written to the binary file ... the steps are :
> >
> > - set the permissions to write only for lock file
> > - set the command option to F_SETLKW
> > - set the lock type option to F_WRLCK
> > - Open the lock file file
> > - Lock the Lock File
>
> (Open the binary file here!)
>
> > - Write to the binary file
> > - Close the binary file
> > - Close the lock file
>
> Where do you open the binary file? If you do it after locking the lock
> file, then you're OK with standard writes. If not, then you're violating
> close-to-open cache consistency, and should rather be using O_DIRECT
> writes.
>
> Cheers
>   Trond
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux-nfs.org/pipermail/nfsv4/attachments/20071002/233411ea/attachment.htm