Help wanted: ENOCLK returned during lock test#2 in connectathon's test

DISCUSSION DENIEL Philippe 4 participants 6 messages Dec 5, 2011 – Dec 7, 2011

Subsystems (2)

NFS client NFS server

lore

Share & tools

lore

DENIEL Philippe

author

2011-12-05 14:02 UTC #0 lore raw

Hi,

as you may know (we may have met at Bake-A-Thon), I am working on NFS-Ganesha, a NFS server running in userspace. I currently face an issue when running cthon04 test suite, during the "lock step". Client is linux 3.1.0-rc4, server is nfs-ganesha compiled with FSAL_VFS support. Server is mounted via command "mount -overs=4.minorversion=1,lock <server>:<path> /mnt"

During the test#2 in "lock" tests, I got the following error:

Creating parent/child synchronization pipes.

Test #2 - Try to lock the whole file.
Parent: 2.0 - F_TLOCK [ 0, ENDING]
FAILED!
Parent: **** Expected success, returned errno=37...
Parent: **** Probably implementation error.

** PARENT pass 1 results: 0/0 pass, 0/0 warn, 1/1 fail (pass/total).

** CHILD pass 1 results: 0/0 pass, 0/0 warn, 0/0 fail (pass/total).

I made a wireshark capture of the packet (see attachement). Apparently, the client does 2 compounds, one for OP4_OPEN and a second to call OP4_OPEN_CONFIRM.

On the client side, the "locl/locklfs" binary fails when calling lockf() (this is not the first time it calls it, it has been done in test#1 which passed successfully). Error return is ENOLCK (posix error #37). I enabled the kernel's debug message by using the command 'echo 32767 > /proc/sys/sunrpc/nfs_debug' (complete log in attachement, reduced to what is related to lock#2). Grepping 'NFS' in this shows this:

   Dec  5 13:31:08 aury63 kernel: NFS: nfs_update_inode(0:16/523265
   ct=2 info=0x27e7f)
   Dec  5 13:31:08 aury63 kernel: NFS: permission(0:16/523265),
   mask=0x1, res=0
   Dec  5 13:31:08 aury63 kernel: NFS: nfs_lookup_revalidate(/rep) is valid
   Dec  5 13:31:08 aury63 kernel: NFS: nfs_update_inode(0:16/544895
   ct=1 info=0x27e7f)
   Dec  5 13:31:08 aury63 kernel: NFS: permission(0:16/544895),
   mask=0x1, res=0
   Dec  5 13:31:08 aury63 kernel: NFS: permission(0:16/544895),
   mask=0x1, res=0
   Dec  5 13:31:08 aury63 kernel: NFS: atomic_lookup(0:16/544895),
   lockfile2908
   Dec  5 13:31:08 aury63 kernel: decode_attr_pnfstype: bitmap is 0
   Dec  5 13:31:08 aury63 kernel: nfs4_schedule_state_renewal:
   requeueing work. Lease period = 80
   Dec  5 13:31:08 aury63 kernel: --> nfs_put_client({2})
   Dec  5 13:31:08 aury63 kernel: <-- nfs4_setup_sequence status=0
   Dec  5 13:31:08 aury63 kernel: NFS: nfs_update_inode(0:16/544895
   ct=1 info=0x27e67)
   Dec  5 13:31:08 aury63 kernel: NFS: change_attr change on server for
   file 0:16/544895
   Dec  5 13:31:08 aury63 kernel: NFS: mtime change on server for file
   0:16/544895
   Dec  5 13:31:08 aury63 kernel: NFS: nfs_fhget(0:16/544930 ct=1)
   Dec  5 13:31:08 aury63 kernel: NFS: open file(rep/lockfile2908)
   Dec  5 13:31:08 aury63 kernel: NFS: permission(0:16/544930),
   mask=0x26, res=0
   Dec  5 13:31:08 aury63 kernel: NFS: lock(rep/lockfile2908, t=1,
   fl=1, r=0:9223372036854775807)

I can see no reason why ENOLCK is returned. This is clearly a bug on the server handside (within nfs-ganesha) but I have to know what the client is doing here to have a clearer idea. I ran the same test using NFSv4.1 and NFSv3+NLMv4, things go perfectly OK with no failure.

Can someone help me ?

Regards

Philippe

Dec  5 13:31:08 aury63 kernel: encode_compound: tag=
Dec  5 13:31:08 aury63 kernel: decode_attr_type: type=040000
Dec  5 13:31:08 aury63 kernel: decode_attr_change: change attribute=1323082676
Dec  5 13:31:08 aury63 kernel: decode_attr_size: file size=856064
Dec  5 13:31:08 aury63 kernel: decode_attr_fsid: fsid=(0xc0/0xa8)
Dec  5 13:31:08 aury63 kernel: decode_attr_fileid: fileid=523265
Dec  5 13:31:08 aury63 kernel: decode_attr_fs_locations: fs_locations done, error = 0
Dec  5 13:31:08 aury63 kernel: decode_attr_mode: file mode=01777
Dec  5 13:31:08 aury63 kernel: decode_attr_nlink: nlink=14
Dec  5 13:31:08 aury63 kernel: decode_attr_owner: uid=0
Dec  5 13:31:08 aury63 kernel: decode_attr_group: gid=0
Dec  5 13:31:08 aury63 kernel: decode_attr_rdev: rdev=(0x0:0x0)
Dec  5 13:31:08 aury63 kernel: decode_attr_space_used: space used=860160
Dec  5 13:31:08 aury63 kernel: decode_attr_time_access: atime=1323081627
Dec  5 13:31:08 aury63 kernel: decode_attr_time_metadata: ctime=1323082676
Dec  5 13:31:08 aury63 kernel: decode_attr_time_modify: mtime=1323082676
Dec  5 13:31:08 aury63 kernel: decode_attr_mounted_on_fileid: fileid=0
Dec  5 13:31:08 aury63 kernel: decode_getfattr: xdr returned 0
Dec  5 13:31:08 aury63 kernel: NFS: nfs_update_inode(0:16/523265 ct=2 info=0x27e7f)
Dec  5 13:31:08 aury63 kernel: NFS: permission(0:16/523265), mask=0x1, res=0
Dec  5 13:31:08 aury63 kernel: NFS: nfs_lookup_revalidate(/rep) is valid
Dec  5 13:31:08 aury63 kernel: encode_compound: tag=
Dec  5 13:31:08 aury63 kernel: decode_attr_type: type=040000
Dec  5 13:31:08 aury63 kernel: decode_attr_change: change attribute=1323088137
Dec  5 13:31:08 aury63 kernel: decode_attr_size: file size=4096
Dec  5 13:31:08 aury63 kernel: decode_attr_fsid: fsid=(0xc0/0xa8)
Dec  5 13:31:08 aury63 kernel: decode_attr_fileid: fileid=544895
Dec  5 13:31:08 aury63 kernel: decode_attr_fs_locations: fs_locations done, error = 0
Dec  5 13:31:08 aury63 kernel: decode_attr_mode: file mode=0755
Dec  5 13:31:08 aury63 kernel: decode_attr_nlink: nlink=2
Dec  5 13:31:08 aury63 kernel: decode_attr_owner: uid=0
Dec  5 13:31:08 aury63 kernel: decode_attr_group: gid=0
Dec  5 13:31:08 aury63 kernel: decode_attr_rdev: rdev=(0x0:0x0)
Dec  5 13:31:08 aury63 kernel: decode_attr_space_used: space used=4096
Dec  5 13:31:08 aury63 kernel: decode_attr_time_access: atime=1323071853
Dec  5 13:31:08 aury63 kernel: decode_attr_time_metadata: ctime=1323088137
Dec  5 13:31:08 aury63 kernel: decode_attr_time_modify: mtime=1323088137
Dec  5 13:31:08 aury63 kernel: decode_attr_mounted_on_fileid: fileid=0
Dec  5 13:31:08 aury63 kernel: decode_getfattr: xdr returned 0
Dec  5 13:31:08 aury63 kernel: NFS: nfs_update_inode(0:16/544895 ct=1 info=0x27e7f)
Dec  5 13:31:08 aury63 kernel: NFS: permission(0:16/544895), mask=0x1, res=0
Dec  5 13:31:08 aury63 kernel: NFS: permission(0:16/544895), mask=0x1, res=0
Dec  5 13:31:08 aury63 kernel: NFS: atomic_lookup(0:16/544895), lockfile2908
Dec  5 13:31:08 aury63 kernel: encode_compound: tag=
Dec  5 13:31:08 aury63 kernel: encode_compound: tag=
Dec  5 13:31:08 aury63 kernel: decode_attr_lease_time: file size=120
Dec  5 13:31:08 aury63 kernel: decode_attr_maxfilesize: maxfilesize=0
Dec  5 13:31:08 aury63 kernel: decode_attr_maxread: maxread=1024
Dec  5 13:31:08 aury63 kernel: decode_attr_maxwrite: maxwrite=1024
Dec  5 13:31:08 aury63 kernel: decode_attr_pnfstype: bitmap is 0
Dec  5 13:31:08 aury63 kernel: decode_attr_layout_blksize: bitmap is 0
Dec  5 13:31:08 aury63 kernel: decode_fsinfo: xdr returned 0!
Dec  5 13:31:08 aury63 kernel: nfs4_schedule_state_renewal: requeueing work. Lease period = 80
Dec  5 13:31:08 aury63 kernel: --> nfs_put_client({2})
Dec  5 13:31:08 aury63 kernel: <-- nfs4_setup_sequence status=0
Dec  5 13:31:08 aury63 kernel: encode_compound: tag=
Dec  5 13:31:08 aury63 kernel: decode_attr_type: type=0100000
Dec  5 13:31:08 aury63 kernel: decode_attr_change: change attribute=1323088268
Dec  5 13:31:08 aury63 kernel: decode_attr_size: file size=0
Dec  5 13:31:08 aury63 kernel: decode_attr_fsid: fsid=(0xc0/0xa8)
Dec  5 13:31:08 aury63 kernel: decode_attr_fileid: fileid=544930
Dec  5 13:31:08 aury63 kernel: decode_attr_fs_locations: fs_locations done, error = 0
Dec  5 13:31:08 aury63 kernel: decode_attr_mode: file mode=0644
Dec  5 13:31:08 aury63 kernel: decode_attr_nlink: nlink=1
Dec  5 13:31:08 aury63 kernel: decode_attr_owner: uid=-2
Dec  5 13:31:08 aury63 kernel: decode_attr_group: gid=-2
Dec  5 13:31:08 aury63 kernel: decode_attr_rdev: rdev=(0x0:0x0)
Dec  5 13:31:08 aury63 kernel: decode_attr_space_used: space used=0
Dec  5 13:31:08 aury63 kernel: decode_attr_time_access: atime=1323088268
Dec  5 13:31:08 aury63 kernel: decode_attr_time_metadata: ctime=1323088268
Dec  5 13:31:08 aury63 kernel: decode_attr_time_modify: mtime=1323088268
Dec  5 13:31:08 aury63 kernel: decode_attr_mounted_on_fileid: fileid=0
Dec  5 13:31:08 aury63 kernel: decode_getfattr: xdr returned 0
Dec  5 13:31:08 aury63 kernel: decode_attr_type: type=040000
Dec  5 13:31:08 aury63 kernel: decode_attr_change: change attribute=1323088137
Dec  5 13:31:08 aury63 kernel: decode_attr_size: file size=4096
Dec  5 13:31:08 aury63 kernel: decode_attr_fsid: fsid=(0xc0/0xa8)
Dec  5 13:31:08 aury63 kernel: decode_attr_fileid: fileid=544895
Dec  5 13:31:08 aury63 kernel: decode_attr_fs_locations: fs_locations done, error = 0
Dec  5 13:31:08 aury63 kernel: decode_attr_mode: file mode=0755
Dec  5 13:31:08 aury63 kernel: decode_attr_nlink: nlink=2
Dec  5 13:31:08 aury63 kernel: decode_attr_owner: uid=-2
Dec  5 13:31:08 aury63 kernel: decode_attr_group: gid=-2
Dec  5 13:31:08 aury63 kernel: decode_attr_rdev: rdev=(0x0:0x0)
Dec  5 13:31:08 aury63 kernel: decode_attr_space_used: space used=4096
Dec  5 13:31:08 aury63 kernel: decode_attr_time_access: atime=1323071853
Dec  5 13:31:08 aury63 kernel: decode_attr_time_metadata: ctime=1323088268
Dec  5 13:31:08 aury63 kernel: decode_attr_time_modify: mtime=1323088268
Dec  5 13:31:08 aury63 kernel: decode_attr_mounted_on_fileid: fileid=0
Dec  5 13:31:08 aury63 kernel: decode_getfattr: xdr returned 0
Dec  5 13:31:08 aury63 kernel: NFS: nfs_update_inode(0:16/544895 ct=1 info=0x27e67)
Dec  5 13:31:08 aury63 kernel: NFS: change_attr change on server for file 0:16/544895
Dec  5 13:31:08 aury63 kernel: NFS: mtime change on server for file 0:16/544895
Dec  5 13:31:08 aury63 kernel: encode_compound: tag=
Dec  5 13:31:08 aury63 kernel: NFS: nfs_fhget(0:16/544930 ct=1)
Dec  5 13:31:08 aury63 kernel: NFS: open file(rep/lockfile2908)
Dec  5 13:31:08 aury63 kernel: NFS: permission(0:16/544930), mask=0x26, res=0
Dec  5 13:31:08 aury63 kernel: NFS: lock(rep/lockfile2908, t=1, fl=1, r=0:9223372036854775807)

Trond Myklebust

2011-12-05 23:33 UTC #1 lore raw

Quoted 19 lines · DENIEL Philippe

Hi,
as you may know (we may have met at Bake-A-Thon), I am working on NFS-Ganesha, a NFS server running in userspace. I currently face an issue when running cthon04 test suite, during the "lock step". Client is linux 3.1.0-rc4, server is nfs-ganesha compiled with FSAL_VFS support. Server is mounted via command "mount -overs=4.minorversion=1,lock <server>:<path> /mnt"
During the test#2 in "lock" tests, I got the following error:
Creating parent/child synchronization pipes.
Test #2 - Try to lock the whole file.
Parent: 2.0 - F_TLOCK [ 0, ENDING]
FAILED!
Parent: **** Expected success, returned errno=37...
Parent: **** Probably implementation error.

Quoted 8 lines

** PARENT pass 1 results: 0/0 pass, 0/0 warn, 1/1 fail (pass/total).
** CHILD pass 1 results: 0/0 pass, 0/0 warn, 0/0 fail (pass/total).
I made a wireshark capture of the packet (see attachement). Apparently, the client does 2 compounds, one for OP4_OPEN and a second to call OP4_OPEN_CONFIRM.

Hi Philippe,

As far as I can see from the pcap file, your server isn't setting the OPEN4_RESULT_LOCKTYPE_POSIX flag in the OPEN reply, and so the client can't support posix locking semantics. In that case, it will return ENOLCK to all fcntl locking requests.

Cheers
Trond

Signature · 6 lines

Trond Myklebust
Linux NFS client maintainer

NetApp
[email protected]
www.netapp.com

DENIEL Philippe

author

2011-12-06 12:11 UTC #2 lore raw

Hi Trond,

many thanks for your reply.
In fact, the "rflag" in OP4_OPEN's reply is set to 6 = 4|2 = OPEN4_RESULT_LOCKTYPE_POSIX|OPEN4_RESULT_CONFIRM
For some reason I do not understand, wireshark see OPEN4_RESULT_LOCKTYPE_POSIX as an 'unknown' flag and do not print it. Bug actually it seems like OPEN4_RESULT_LOCKTYPE_POSIX is set.

Your mail made me have a closer look to my implementation of OP4_OPEN and OP4_OPEN_CONFIRM in NFSv4.0 . Since the beginning (since I met this bug), I suspect something related to seqids : it does not occur in NFSv4.1 where seqids 's management is made in OP4_SEQUENCE, at the beginning of the request. So I ran lock test#2 on a kernel nfsd, capture the result and compared to what ganesha produces. I saw a difference:
- when OP4_OPEN is invoked, the nfsd replies with a stateid containing seqid=0. This seqid is passed to OP4_OPEN_CONFIRM which confirms it and (if OK) replies with an updated stateid (seqid is now 1)
- when ganesha does the same OP4_OPEN return a (unconfirmed) stateid whose seqid is equal to 1, then OP4_OPEN_CONFIRM set this seqid to 2 when confirming the stateid.

From your point of view, could this mess in seqid's management produce the bug that I see when running lock test#2 ?

Regards

Philippe

Quoted 36 lines · Trond Myklebust

Quoted 16 lines · DENIEL Philippe
Hi,
as you may know (we may have met at Bake-A-Thon), I am working on NFS-Ganesha, a NFS server running in userspace. I currently face an issue when running cthon04 test suite, during the "lock step". Client is linux 3.1.0-rc4, server is nfs-ganesha compiled with FSAL_VFS support. Server is mounted via command "mount
-overs=4.minorversion=1,lock <server>:<path> /mnt"
During the test#2 in "lock" tests, I got the following error:
Creating parent/child synchronization pipes.
Test #2 - Try to lock the whole file.
Parent: 2.0 - F_TLOCK [ 0, ENDING]
FAILED!
Parent: **** Expected success, returned errno=37...
Parent: **** Probably implementation error.
Quoted 7 lines
** PARENT pass 1 results: 0/0 pass, 0/0 warn, 1/1 fail (pass/total).
** CHILD pass 1 results: 0/0 pass, 0/0 warn, 0/0 fail (pass/total).
I made a wireshark capture of the packet (see attachement). Apparently, the client does 2 compounds, one for OP4_OPEN and a second to call OP4_OPEN_CONFIRM.
Hi Philippe,
As far as I can see from the pcap file, your server isn't setting the OPEN4_RESULT_LOCKTYPE_POSIX flag in the OPEN reply, and so the client can't support posix locking semantics. In that case, it will return ENOLCK to all fcntl locking requests.
Cheers
Trond

J. Bruce Fields

2011-12-06 19:37 UTC #3 lore raw

Quoted 9 lines · DENIEL Philippe

Hi Trond,
many thanks for your reply.
In fact, the "rflag" in OP4_OPEN's reply is set to 6 = 4|2 = OPEN4_RESULT_LOCKTYPE_POSIX|OPEN4_RESULT_CONFIRM
For some reason I do not understand, wireshark see OPEN4_RESULT_LOCKTYPE_POSIX as an 'unknown' flag and do not print it. Bug actually it seems like OPEN4_RESULT_LOCKTYPE_POSIX is set.

Quoted 14 lines

Your mail made me have a closer look to my implementation of OP4_OPEN and OP4_OPEN_CONFIRM in NFSv4.0 . Since the beginning (since I met this bug), I suspect something related to seqids : it does not occur in NFSv4.1 where seqids 's management is made in OP4_SEQUENCE, at the beginning of the request. So I ran lock test#2 on a kernel nfsd, capture the result and compared to what ganesha produces. I saw a difference:
- when OP4_OPEN is invoked, the nfsd replies with a stateid containing seqid=0. This seqid is passed to OP4_OPEN_CONFIRM which confirms it and (if OK) replies with an updated stateid (seqid is now 1)
- when ganesha does the same OP4_OPEN return a (unconfirmed) stateid whose seqid is equal to 1, then OP4_OPEN_CONFIRM set this seqid to 2 when confirming the stateid.

Sounds like you're talking about the seqid field that's contained in the stateid itself--I'd be suprised if the client cares about it. The spec does allow the client to inspect that field to decide what order opens were done in, but other than that a client normally treats the whole stateid as opaque.

--b.

Quoted 53 lines

From your point of view, could this mess in seqid's management produce the bug that I see when running lock test#2 ?
Regards
Philippe
Quoted 32 lines · Trond Myklebust
Quoted 20 lines · DENIEL Philippe
Hi,
as you may know (we may have met at Bake-A-Thon), I am working on NFS-Ganesha, a NFS server running in userspace. I currently face an issue when running cthon04 test suite, during the "lock step".
Client is linux 3.1.0-rc4, server is nfs-ganesha compiled with FSAL_VFS support. Server is mounted via command "mount -overs=4.minorversion=1,lock <server>:<path> /mnt"
During the test#2 in "lock" tests, I got the following error:
Creating parent/child synchronization pipes.
Test #2 - Try to lock the whole file.
Parent: 2.0 - F_TLOCK [ 0, ENDING]
FAILED!
Parent: **** Expected success, returned errno=37...
Parent: **** Probably implementation error.
Quoted 8 lines
   ** PARENT pass 1 results: 0/0 pass, 0/0 warn, 1/1 fail (pass/total).

   **  CHILD pass 1 results: 0/0 pass, 0/0 warn, 0/0 fail (pass/total).
I made a wireshark capture of the packet (see attachement). Apparently, the client does 2 compounds, one for OP4_OPEN and a second to call OP4_OPEN_CONFIRM.
Hi Philippe,
Quoted 7 lines
As far as I can see from the pcap file, your server isn't setting the OPEN4_RESULT_LOCKTYPE_POSIX flag in the OPEN reply, and so the client can't support posix locking semantics. In that case, it will return ENOLCK to all fcntl locking requests.
Cheers
Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

DENIEL Philippe

author

2011-12-07 14:25 UTC #4 lore raw

Hi Bruce,

Yes I am talking about the seqid inside the stateid.

Philippe

Quoted 91 lines · J. Bruce Fields

Quoted 9 lines · DENIEL Philippe
Hi Trond,
many thanks for your reply.
In fact, the "rflag" in OP4_OPEN's reply is set to 6 = 4|2 = OPEN4_RESULT_LOCKTYPE_POSIX|OPEN4_RESULT_CONFIRM
For some reason I do not understand, wireshark see OPEN4_RESULT_LOCKTYPE_POSIX as an 'unknown' flag and do not print it. Bug actually it seems like OPEN4_RESULT_LOCKTYPE_POSIX is set.
Quoted 15 lines
Your mail made me have a closer look to my implementation of OP4_OPEN and OP4_OPEN_CONFIRM in NFSv4.0 . Since the beginning (since I met this bug), I suspect something related to seqids : it does not occur in NFSv4.1 where seqids 's management is made in OP4_SEQUENCE, at the beginning of the request. So I ran lock test#2 on a kernel nfsd, capture the result and compared to what ganesha produces. I saw a difference:
- when OP4_OPEN is invoked, the nfsd replies with a stateid containing seqid=0. This seqid is passed to OP4_OPEN_CONFIRM which confirms it and (if OK) replies with an updated stateid (seqid is now 1)
- when ganesha does the same OP4_OPEN return a (unconfirmed) stateid whose seqid is equal to 1, then OP4_OPEN_CONFIRM set this seqid to 2 when confirming the stateid.
Sounds like you're talking about the seqid field that's contained in the stateid itself--I'd be suprised if the client cares about it. The spec does allow the client to inspect that field to decide what order opens were done in, but other than that a client normally treats the whole stateid as opaque.
--b.
Quoted 55 lines
From your point of view, could this mess in seqid's management produce the bug that I see when running lock test#2 ?
Regards
Philippe
Quoted 33 lines · Trond Myklebust
Quoted 20 lines · DENIEL Philippe
Hi,
as you may know (we may have met at Bake-A-Thon), I am working on NFS-Ganesha, a NFS server running in userspace. I currently face an issue when running cthon04 test suite, during the "lock step".
Client is linux 3.1.0-rc4, server is nfs-ganesha compiled with FSAL_VFS support. Server is mounted via command "mount -overs=4.minorversion=1,lock <server>:<path> /mnt"
During the test#2 in "lock" tests, I got the following error:
Creating parent/child synchronization pipes.
Test #2 - Try to lock the whole file.
Parent: 2.0 - F_TLOCK [ 0, ENDING]
FAILED!
Parent: **** Expected success, returned errno=37...
Parent: **** Probably implementation error.
Quoted 9 lines
   ** PARENT pass 1 results: 0/0 pass, 0/0 warn, 1/1 fail (pass/total).

   **  CHILD pass 1 results: 0/0 pass, 0/0 warn, 0/0 fail (pass/total).
I made a wireshark capture of the packet (see attachement). Apparently, the client does 2 compounds, one for OP4_OPEN and a second to call OP4_OPEN_CONFIRM.
Hi Philippe,
Quoted 8 lines
As far as I can see from the pcap file, your server isn't setting the OPEN4_RESULT_LOCKTYPE_POSIX flag in the OPEN reply, and so the client can't support posix locking semantics. In that case, it will return ENOLCK to all fcntl locking requests.
Cheers
Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Frank S Filz

2011-12-07 15:12 UTC #5 lore raw

DENIEL Philippe <[email protected]> wrote on 12/07/2011 05:29:02 AM:

Quoted 3 lines

Hi Bruce,
Yes I am talking about the seqid inside the stateid.

The seqid inside the stateid also should be an unlikely place for a difference between NFS v4 and NFS v4.1 since NFS v4.1 still has the seqid inside the stateid. See 9.4. Stateid Seqid Values and Byte-Range Locks for
locks (p. 189 of rfc5661). See 9.9. Open Upgrade and Downgrade on p. 192
for open.

Frank

Quoted 28 lines

Quoted 27 lines · J. Bruce Fields
Quoted 24 lines · DENIEL Philippe
Hi Trond,
many thanks for your reply.
In fact, the "rflag" in OP4_OPEN's reply is set to 6 = 4|2 = OPEN4_RESULT_LOCKTYPE_POSIX|OPEN4_RESULT_CONFIRM
For some reason I do not understand, wireshark see OPEN4_RESULT_LOCKTYPE_POSIX as an 'unknown' flag and do not print it. Bug actually it seems like OPEN4_RESULT_LOCKTYPE_POSIX is set.
Your mail made me have a closer look to my implementation of OP4_OPEN and OP4_OPEN_CONFIRM in NFSv4.0 . Since the beginning (since I met this bug), I suspect something related to seqids : it does not occur in NFSv4.1 where seqids 's management is made in OP4_SEQUENCE, at the beginning of the request. So I ran lock test#2 on a kernel nfsd, capture the result and compared to what ganesha produces. I saw a difference:
- when OP4_OPEN is invoked, the nfsd replies with a stateid containing seqid=0. This seqid is passed to OP4_OPEN_CONFIRM which confirms it and (if OK) replies with an updated stateid (seqid is now 1)
- when ganesha does the same OP4_OPEN return a (unconfirmed) stateid whose seqid is equal to 1, then OP4_OPEN_CONFIRM set this seqid to 2 when confirming the stateid.

Quoted 1 line

Quoted 1 line
Sounds like you're talking about the seqid field that's contained in

the

Quoted 29 lines

Quoted 29 lines
stateid itself--I'd be suprised if the client cares about it. The spec does allow the client to inspect that field to decide what order opens were done in, but other than that a client normally treats the whole stateid as opaque.
--b.
Quoted 21 lines
From your point of view, could this mess in seqid's management produce the bug that I see when running lock test#2 ?
Regards
Philippe
Quoted 12 lines · Trond Myklebust
Quoted 10 lines · DENIEL Philippe
Hi,
as you may know (we may have met at Bake-A-Thon), I am working on NFS-Ganesha, a NFS server running in userspace. I currently face an issue when running cthon04 test suite, during the "lock step".
Client is linux 3.1.0-rc4, server is nfs-ganesha compiled with FSAL_VFS support. Server is mounted via command "mount -overs=4.minorversion=1,lock <server>:<path> /mnt"

Quoted 6 lines

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
During the test#2 in "lock" tests, I got the following error:
Creating parent/child synchronization pipes.
Test #2 - Try to lock the whole file.
Parent: 2.0 - F_TLOCK [ 0,

ENDING]

Quoted 5 lines

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
FAILED!
Parent: **** Expected success, returned errno=37...
Parent: **** Probably implementation error.
   ** PARENT pass 1 results: 0/0 pass, 0/0 warn, 1/1 fail

(pass/total).

Quoted 2 lines

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
   **  CHILD pass 1 results: 0/0 pass, 0/0 warn, 0/0 fail

(pass/total).

Quoted 13 lines

Quoted 13 lines
Quoted 13 lines
Quoted 13 lines
Quoted 6 lines
I made a wireshark capture of the packet (see attachement). Apparently, the client does 2 compounds, one for OP4_OPEN and a second to call OP4_OPEN_CONFIRM.
Hi Philippe,
As far as I can see from the pcap file, your server isn't setting the OPEN4_RESULT_LOCKTYPE_POSIX flag in the OPEN reply, and so the client can't support posix locking semantics. In that case, it will return ENOLCK to all fcntl locking requests.

Quoted 5 lines

Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
Cheers
Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs"

Quoted 6 lines

Quoted 3 lines
Quoted 3 lines
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

------------------------------------------------------------------------------

Quoted 2 lines

Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point

Quoted 1 line

discussion for anyone considering optimizing the pricing and packaging

model

Quoted 6 lines

of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
_______________________________________________
Nfs-ganesha-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel