Bug 1090986
Summary: | DHT + Snapshot :- If snapshot is taken when Directory is created only on hashed sub-vol; On restoring that snapshot Directory is not listed on mount point and lookup on parent is not healing | |||
---|---|---|---|---|
Product: | [Red Hat Storage] Red Hat Gluster Storage | Reporter: | Rachana Patel <racpatel> | |
Component: | distribute | Assignee: | Susant Kumar Palai <spalai> | |
Status: | CLOSED ERRATA | QA Contact: | amainkar | |
Severity: | high | Docs Contact: | ||
Priority: | high | |||
Version: | rhgs-3.0 | CC: | bbandari, kdhananj, khiremat, nsathyan, psriniva, rgowdapp, spalai, ssamanta | |
Target Milestone: | --- | |||
Target Release: | RHGS 3.0.0 | |||
Hardware: | x86_64 | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | glusterfs-3.6.0.27-1 | Doc Type: | Bug Fix | |
Doc Text: |
Previously the directory entries were added only from the first_up_subvol(brick online for the longest duration of time). If the directory was created on a hashed-brick and soon after if a snapshot was taken, the restored snapshot mount point did not list the directory entry.
With this fix, the directory entries are filtered from the corresponding hashed subvolumes. Only in case of a hashed subvolume having a NULL value (either because of a layout anomaly or the hashed volume being offline), the entry is filtered from the first_up_subvol.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1092433 (view as bug list) | Environment: | ||
Last Closed: | 2014-09-22 19:36:03 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1092433, 1092501, 1139103, 1139986 |
Description
Rachana Patel
2014-04-24 14:24:50 UTC
Able to reproduce without taking snapshot. Steps:- 1) send Directory creation from one mount point. 2) When Directory is created on hashed and not not creates on other sub-volumes(non hashed), send lookup from other mount point --> lookup is not healin Directory on other sub-volumes *** Bug 1092501 has been marked as a duplicate of this bug. *** Upstream patch : http://review.gluster.org/#/c/7599/ verified with build 3.6.0.20-1.el6rhs.x86_64 works as per expectation hence moving to verified Hi Susant, Please review the edited doc text for technical accuracy and sign off. Hi Susant, Please review the edited doc text for technical accuracy and sign off. I was able to hit this issue on the build glusterfs-3.6.0.25-1. 1. create and start Distributed replicate master and slave volume, and create geo-rep relationship between master and slave (looks like geo-rep has nothing to do with this issue) 2. create Directory from mount point on master and make sure you take a snap of volume when Directory is created only on one of the sub-volume and not on any other. 3. restore snap (follow steps to restore snap) 4. mount volume again and list out content of parent Directory. newly created Directory is not listed. I also could be able to hit this during snapshot restoration of geo-rep slave and master. A directory in restored master volume was only present in one brick and not on other. Gluster mount could not see the directory. Lookup on parent directory did not heal it but the lookup on the missing directory healed. Root Cause of the issue: Due to snapshot and mkdir race, snapshot took the entry from the non-hashed and not hashed. As dht_readdirp fop depends on the entry being present on the hashed subvolume to be filtered, the entry was not shown on the mount point and also not healed for the master volume. [Hence, not a regression] Relation to geo-rep: The changlogs are captured at the brick level at the master and since one of the bricks has the directory entry, geo-rep syncs the directory on to the slave. Now the inconsistency being the slave has an entry which the master does not have from the gluster mount point. So closing this bug as it is not a regression and a new bug need to be created to track the geo-rep inconsistencies. Moving this to ON_QA. If the snapshot has captured the entry from the mkdir on the hashed subvol and still the entry does not get listed on the mount point reopen this bug. Issue mentioned in the comment 17 is being tracked with the Bug 1128155 verified with 3.6.0.28-1.el6rhs.x86_64, working as expected hence moving to verified Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2014-1278.html |