Bug 139553 - lock tests on nfs mount point are failing in nfs version 2 and version 3.
Summary: lock tests on nfs mount point are failing in nfs version 2 and version 3.
Status: VERIFIED FIXED
Alias: None
Product: SUSE Linux 10.1
Classification: openSUSE
Component: Other (show other bugs)
Version: Alpha 3
Hardware: Other Other
: P5 - None : Major (vote)
Target Milestone: ---
Assignee: Olaf Kirch
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-16 09:43 UTC by Anilkumar Bolleni
Modified: 2006-01-18 05:01 UTC (History)
1 user (show)

See Also:
Found By: Component Test
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anilkumar Bolleni 2005-12-16 09:43:19 UTC
OS:
SUSE LINUX 10.1 alpha3 .
steps:
I started all nfsv4 deamons on server.
rpc.mountd
rpc.idmapd
rpc.svcgssd
nfsserver 
exported paths using fallowing options
/export *(rw,fsid=0,insecure,no_subtree_check,sync)
/export  gss/krb5(rw,fsid=0,insecure,no_subtree_check,sync)
/export  gss/krb5i(rw,fsid=0,insecure,no_subtree_check,sync)
/export  gss/krb5p(rw,fsid=0,insecure,no_subtree_check,sync)
I used solaries as nfs client.
dowloaded connectathon testsuite from  fallowing link http://www.connectathon.org/nfstests.html and configured for solaries .
run lock tests for nfs server exported path.

from top directory of connectathon tests  run
./server -l -o vers=3,proto=tcp -p /export -m /mnt1 <serverip>

Results:
Testing native post-LFS locking

Creating parent/child synchronization pipes.

Test #1 - Test regions of an unlocked file.
        Parent: 1.1  - F_TEST  [       0,       1] PASSED.
        Parent: 1.2  - F_TEST  [       0,  ENDING] PASSED.
        Parent: 1.3  - F_TEST  [       0,7fffffff] PASSED.
        Parent: 1.4  - F_TEST  [       1,       1] PASSED.
        Parent: 1.5  - F_TEST  [       1,  ENDING] PASSED.
        Parent: 1.6  - F_TEST  [       1,7fffffff] PASSED.
        Parent: 1.7  - F_TEST  [7fffffff,       1] PASSED.
        Parent: 1.8  - F_TEST  [7fffffff,  ENDING] PASSED.
        Parent: 1.9  - F_TEST  [7fffffff,7fffffff] PASSED.

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

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

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

for both nfs version 2 and version 3 this lock tests are failing.
Comment 1 Chris L Mason 2005-12-19 17:38:59 UTC
Neil, please help.
Comment 2 Olaf Kirch 2005-12-19 18:48:37 UTC
Of course they fail; I haven't forward ported kernel statd yet, and we
do not have a user space statd.

*** This bug has been marked as a duplicate of 132481 ***
Comment 3 Anilkumar Bolleni 2005-12-20 10:33:08 UTC
 from above comment you mean that lock tests for nfs version 2 and version 3 also fail without ported kernel statd. it's not only nfsv4 requires ported statd .
Comment 4 Anilkumar Bolleni 2006-01-09 04:49:12 UTC
This lock tests have nothing to do with nfsv4 deamons. As, this tests are releated to v2 and v3 this should pass irrespective v4 deamons. and I am seeing this tests failing in SLES10 preview1 builds also.so, I am reopening this defect.
 
Comment 5 Neil Brown 2006-01-10 07:26:47 UTC
statd isn't a v4 daemon.

SL10 currently has no user-mode statd, and no kernel-mode statd.

So locking doesn't work.
Comment 6 Olaf Kirch 2006-01-10 08:42:17 UTC
Anilkumar, we did not have working statd support in the SLES10 kernels
until a few days ago.

File locking in NFSv2 and NFSv3 requires lockd and statd support.

File locking in NFSv4 is done in-band, as part of the v4 protocol itself,
and does not require additional daemons.

Please test again with a current KOTD. Thanks
Comment 7 Anilkumar Bolleni 2006-01-18 05:01:31 UTC
I tested this in SLES preview4 build . all lock tests in V2 and V3 are passing.