Bug 1615096 - ./tests/bugs/quick-read/bug-846240.t fails spuriously
Summary: ./tests/bugs/quick-read/bug-846240.t fails spuriously
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: quick-read
Version: mainline
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Raghavendra G
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-08-12 10:15 UTC by Raghavendra G
Modified: 2018-10-23 15:17 UTC (History)
1 user (show)

Fixed In Version: glusterfs-5.0
Clone Of:
Environment:
Last Closed: 2018-10-23 15:17:10 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Raghavendra G 2018-08-12 10:15:43 UTC
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:

Comment 1 Worker Ant 2018-08-12 10:19:32 UTC
REVIEW: https://review.gluster.org/20710 (tests/quick-read/bug-846240.t: fix a wrong test) posted (#1) for review on master by Raghavendra G

Comment 2 Worker Ant 2018-08-13 12:46:11 UTC
COMMIT: https://review.gluster.org/20710 committed in master by "Shyamsundar Ranganathan" <srangana> with a commit message- tests/quick-read/bug-846240.t: fix a wrong test

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.

Change-Id: I739f255e0a62ff0024f0824dad3539974955df99
Signed-off-by: Raghavendra G <rgowdapp>
Fixes: bz#1615096

Comment 3 Shyamsundar 2018-10-23 15:17:10 UTC
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-5.0, please open a new bug report.

glusterfs-5.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] https://lists.gluster.org/pipermail/announce/2018-October/000115.html
[2] https://www.gluster.org/pipermail/gluster-users/


Note You need to log in before you can comment on or make changes to this bug.