Red Hat Bugzilla – Bug 435428
test6 and test7 basic connectathon tests fail between RHEL5 and AIX
Last modified: 2010-03-16 15:14:22 EDT
Description of problem:
Running the basic commands (-b) of the Connectathon Suite between AIX 6.1.0 SP2
(as NFSV4 Client) and Linux 2.6.24-rc2-CITI_NFS4_ALL-1(as NFSV4 server), I get
issues in test6 and test7 which should be due to the change attribute of 1s on
the server side:
- for test6 we get:
./runtests -b -t /mnt/nosec/test6
Starting BASIC tests: test directory /mnt/nosec/test6 (arg: -t)
./test6: (/mnt/nosec/test6) unlinked 'file.0' dir entry read pass 1
./test6: (/mnt/nosec/test6) Test failed with 1 errors basic tests failed
- for test7 we get:
./runtests -b -t /mnt/nosec/test7
Starting BASIC tests: test directory /mnt/nosec/test7 (arg: -t)
./test7: link and rename
./test7: (/mnt/nosec/test7) file.0 has 2 links after unlink (expect 1) :
No such file or directory
basic tests failed
Version-Release number of selected component (if applicable):
AIX 6.1.0 SP2
Steps to Reproduce:
If we mount on the AIX side with noac it works.
If we add also "sleep(1)" before the unlink it works
Otherwise it fails
Here is the IBM's analysis:
>>I believe that's the time_delta issue about change attribute.
>>The problem is this.
>> 1. A is a file.
>> 2. B is a link (hard link) to A.
>>So A has 2 links.
>>WWhen client deleted B or A. the link count should go down to 1. When the
>>the link count on A is 2 which is cached on the client side. However, when
client delete B
>>and then ask for the attrributes of A, A hasn't change because deletion and
asking for attributes
>> are all within a second(the time_delta issue). Since A hasn't changed, So
client thinks its
>>cache is good. Therefore a bad link count get reported.
>>By putting a sleep of a second in between rm and ls, we are forcing the client
to sleep for
>>one second before asking for the attributes. Since the time_delta for linux is
>>So when asking for attributes, server will notice the different and tell the
>> its cache has expired. In this case, client will then purge the cache and
>>cache and return the good link count.
Please reopen if this is still an issue.