Bug 1226889
| Summary: | [Backup]: 'New' as well as 'Modify' entry getting recorded for a newly created hardlink | |||
|---|---|---|---|---|
| Product: | [Red Hat Storage] Red Hat Gluster Storage | Reporter: | Sweta Anandpara <sanandpa> | |
| Component: | glusterfind | Assignee: | Saravanakumar <sarumuga> | |
| Status: | CLOSED ERRATA | QA Contact: | Sweta Anandpara <sanandpa> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | rhgs-3.1 | CC: | asrivast, avishwan, khiremat, rgowdapp, rhs-bugs, storage-qa-internal | |
| Target Milestone: | --- | |||
| Target Release: | RHGS 3.1.0 | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | glusterfs-3.7.1-3 | Doc Type: | Bug Fix | |
| Doc Text: |
Cause:
When a file is renamed and the (renamed)file's Hashing falls into a different brick, DHT creates a special file(linkto file) in the brick(Hashed subvolume) and carries out setattr operation on that file. Currently, Changelog records this(setattr) operation in Hashed subvolume.
Consequence:
glusterfind in turn records this operation as MODIFY operation. So, there is a NEW entry in Cached subvolume and MODIFY entry in Hashed subvolume for the same file.
Fix:
Avoid logging setattr operation carried out, by marking the operation as internal fop using xdata. In changelog translator, check whether setattr is set as internal fop and skip accordingly.
Result:
Only NEW entry gets recorded and MODIFY entry is skipped.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1230007 (view as bug list) | Environment: | ||
| Last Closed: | 2015-07-29 04:54:26 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: | 1202842, 1223636, 1230007, 1230687 | |||
|
Description
Sweta Anandpara
2015-06-01 11:51:52 UTC
For instance if a Volume has two bricks b1 and b2, When a Link file name falls to brick b2(different from where it is created, brick b1), DHT create link-to file in brick b2 and actual data file resides in brick b1. Changelog in brick2 should ignore all internal fops, but it is recording Metadata of link-to file. So the output file has two entries(NEW entry from b1 and MODIFY entry from b2). We need to fix in Changelog, to not record these internal fops related to DHT link-to files. Observing the behavior mentioned in the bug in the latest build 3.7.1.3 Pasted below are the logs: [root@dhcp43-93 ~]# [root@dhcp43-93 ~]# glusterfind list SESSION VOLUME SESSION TIME --------------------------------------------------------------------------- sessn2 nash 2015-06-16 17:46:51 sessn3 nash 2015-06-16 17:47:02 sesso1 ozone 2015-06-15 23:48:42 sessn1 nash 2015-06-16 17:54:33 [root@dhcp43-93 ~]# [root@dhcp43-93 ~]# glusterfind post sessn1 nash^C [root@dhcp43-93 ~]# cat /tmp/out.txt MODIFY test2 MODIFY .trashcan%2Finternal_op%2F [root@dhcp43-93 ~]# glusterfind post sessn1 nash Session sessn1 with volume nash updated [root@dhcp43-93 ~]# ############### CLIENT ################ [root@dhcp43-71 ~]# cd /mnt/nn [root@dhcp43-71 nn]# ls dir1 test1 test1ln test2 [root@dhcp43-71 nn]# cd dir1 [root@dhcp43-71 dir1]# ls 1 test2l [root@dhcp43-71 dir1]# [root@dhcp43-71 dir1]# [root@dhcp43-71 dir1]# ln 1 1_link [root@dhcp43-71 dir1]# ########################################### [root@dhcp43-93 ~]# glusterfind pre sessn1 nash /tmp/out.txt Generated output file /tmp/out.txt [root@dhcp43-93 ~]# cat /tmp/out.txt NEW dir1%2F%2F1_link MODIFY dir1%2F1_link [root@dhcp43-93 ~]# glusterfind pre sessn1 nash /tmp/out.txt --regenerate-outfile Generated output file /tmp/out.txt [root@dhcp43-93 ~]# cat /tmp/out.txt NEW dir1%2F%2F1_link MODIFY dir1%2F1_link [root@dhcp43-93 ~]# date Tue Jun 16 18:28:29 IST 2015 [root@dhcp43-93 ~]# glusterfind pre sessn1 nash /tmp/out.txt --regenerate-outfile Generated output file /tmp/out.txt [root@dhcp43-93 ~]# cat /tmp/out.txt NEW dir1%2F%2F1_link MODIFY dir1%2F1_link [root@dhcp43-93 ~]# date Tue Jun 16 18:29:00 IST 2015 [root@dhcp43-93 ~]# glusterfind pre sessn1 nash /tmp/out.txt --regenerate-outfile 10.70.43.155 - pre failed: [2015-06-16 12:59:12.051443] I [event-epoll.c:629:event_dispatch_epoll_worker] 0-epoll: Started thread with index 1 Generated output file /tmp/out.txt [root@dhcp43-93 ~]# cat /tmp/out.txt NEW dir1%2F%2F1_link MODIFY dir1%2F1_link [root@dhcp43-93 ~]# date Tue Jun 16 18:29:39 IST 2015 [root@dhcp43-93 ~]# glusterfind pre sessn1 nash /tmp/out.txt --regenerate-outfile Generated output file /tmp/out.txt [root@dhcp43-93 ~]# cat /tmp/out.txt NEW dir1%2F%2F1_link MODIFY dir1%2F1_link [root@dhcp43-93 ~]# date Tue Jun 16 18:32:43 IST 2015 [root@dhcp43-93 ~]# glusterfind pre sessn1 nash /tmp/out.txt --regenerate-outfile Generated output file /tmp/out.txt [root@dhcp43-93 ~]# cat /tmp/out.txt NEW dir1%2F%2F1_link MODIFY dir1%2F1_link [root@dhcp43-93 ~]# Not hitting this issue after updating the glusterfs build on the client. Server build: glusterfs-3.7.1-3.el6rhs.x86_64 and 3.7.1-4.el6rhs.x86_64 Client build: glusterfs-3.7.1-3.el6.x86_64 Tried multiple scenarios, multiple times on a 2node cluster (with a 2*2 volume) as well as 4node cluster (having a 4*2 volume) and have not hit this issue again. When a hardlink file is created, only a NEW entry is getting logged in teh output file, and no other unexpected entry is seen, regarding the link file. Detailed logs (along with the regression that was run) can be found as an attachment in the link: https://polarion.engineering.redhat.com/polarion/#/project/RHG3/testrun?id=glusterfs-3_7_1_3_RHEL6_7_FUSE Moving this bug to verified in 3.1 Everglades. Correcting the link of log location of the functional testing that was executed in and around this bug, and the rest of the feature: https://polarion.engineering.redhat.com/polarion/testrun-attachment/RHG3/glusterfs-3_7_1_3_RHEL6_7_FUSE/RHG3-5400_Logs_6.7_3.7.1-3_output_file_validation.odt 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. https://rhn.redhat.com/errata/RHSA-2015-1495.html |