Description of problem: Every file/dir/link creation gets recorded as a NEW entry. If a 'glusterfind post' is done, and then any modification is done, then it would get recorded as MODIFY. But when a hardlink is created, there are 2 entries that are getting recorded. NEW as well as MODIFY. Please note that it is not happening for every hardlink that is created. Version-Release number of selected component (if applicable): glusterfs-3.7.0-2.el6rhs.x86_64 How reproducible: Always Steps that I executed: 0. Have a volume 'testvol' and create a glusterfind session 'testvols'. Mount the volume using fuse. 1. Create 3 files 'a', 'b', 'c' 2. Create a link 'a_link' to file 'a' 3. Create a directory 'dir' 4. Create a link 'c_link' to file 'c' 5. Run 'glusterfind pre' and verify the contents of outfput file Actual results: Step5 shows 7 entries, 6 of them NEW and 1 of them MODIFY Expected results: Step5 should show only 6 entries - all of which should be NEW Additional info: ############# client ################### [root@dhcp43-59 ~]# mkdir /mnt/glusterfs [root@dhcp43-59 ~]# mount -t glusterfs 10.70.43.140:/testvol /mnt/glusterfs [root@dhcp43-59 ~]# cd /mnt/glusterfs/ [root@dhcp43-59 glusterfs]# ls -a . .. .trashcan [root@dhcp43-59 glusterfs]# touch a [root@dhcp43-59 glusterfs]# touch b [root@dhcp43-59 glusterfs]# touch c [root@dhcp43-59 glusterfs]# ln a a_link [root@dhcp43-59 glusterfs]# mkdir dir [root@dhcp43-59 glusterfs]# ln c c_link [root@dhcp43-59 glusterfs]# ls a a_link b c c_link dir [root@dhcp43-59 glusterfs]# ############## server ################# [root@dhcp43-140 ~]# [root@dhcp43-140 ~]# glusterfind create testvols testvol [root@dhcp43-140 ~]# glusterfind pre testvols testvol /tmp/outfiles.txt Generated output file /tmp/outfiles.txt [root@dhcp43-140 ~]# cat /tmp/outfiles.txt NEW a NEW b NEW c NEW a_link NEW dir NEW c_link MODIFY c_link [root@dhcp43-140 ~]#
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