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

bugzilla at redhat.com bugzilla at redhat.com
Sun Aug 12 10:15:43 UTC 2018


            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
    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

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

How reproducible:

Steps to Reproduce:

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.

More information about the Bugs mailing list