[Bugs] [Bug 1615096] New: ./tests/bugs/quick-read/bug-846240.t fails spuriously

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1615096

            Bug ID: 1615096
           Summary: ./tests/bugs/quick-read/bug-846240.t fails spuriously
           Product: GlusterFS
           Version: mainline
         Component: quick-read
          Assignee: bugs at gluster.org
          Reporter: rgowdapp at redhat.com
                CC: bugs at gluster.org



Description of problem:

Earlier this test did following things on M0 and M1 mounted on same
    volume:
    1 create file  M0/testfile
    2 open an fd on M0/testfile
    3 remove the file from M1, M1/testfile
    4 echo "data" >> M0/testfile

    The test expects appending data to M0/testfile to fail. However,
    redirector ">>" creates a file if it doesn't exist. So, the only
    reason test succeeded was due to lookup succeeding due to stale stat
    in md-cache. This hypothesis is verified by two experiments:
    * Add a sleep of 10 seconds before append operation. md-cache cache
      expires and lookup fails followed by creation of file and hence append
      succeeds to new file.
    * set md-cache timeout to 600 seconds and test never fails even with
      sleep 10 before append operation. Reason is stale stat in md-cache
      survives sleep 10.

    So, the spurious nature of failure was dependent on whether lookup is
    done when stat is present in md-cache or not.

    The actual test should've been to write to the fd opened in step 2
    above. I've changed the test accordingly. Note that this patch also
    remounts M0 after initial file creation as open-behind disables
    opening-behind on witnessing a setattr on the inode and touch involves
    a setattr. On remount, create operation is not done and hence file is
    opened-behind.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.