Bug 1218383

Summary: [Backup]: To capture path for deletes in changelog file
Product: [Community] GlusterFS Reporter: Kotresh HR <khiremat>
Component: glusterfindAssignee: Kotresh HR <khiremat>
Status: CLOSED CURRENTRELEASE QA Contact: bugs <bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.7.0CC: avishwan, bugs, khiremat, sanandpa
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: glusterfs-3.7.0 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1214561 Environment:
Last Closed: 2015-05-14 17:29:35 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: 1214561    
Bug Blocks: 1186580, 1217935    

Description Kotresh HR 2015-05-04 18:36:21 UTC
+++ This bug was initially created as a clone of Bug #1214561 +++

Description of problem:

Glusterfind API presently is just able to mention the files which have been newly created, or have had data/metadata changes. In case a file is deleted, it is not able to get that information from the changelog file

This bug is to track the progress made on that front.

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

Glusterfs 3.7 upstream

How reproducible: Always

Steps to Reproduce:

1. Have a gluster volume of type distribute/replicate
2. Create 2 files 'file1' and 'file2'
3. Edit the contents of 'file2' 
4. Delete 'file2'
5. Change the permissions of 'file1' to (say) read-only
6. Verify the contents of changelog file.

Actual results:

Step 6 should shows Entry operations for 'file1' and 'file2', followed with Data operation for 'file2', and a Metadata operation for 'file1'
Delete operation of 'file2' (step4) is not recorded in the changelog file.

Expected results:

Delete operation of 'file2' should get recorded in the changelog file, which in turn can be used by Glusterfind.

Comment 1 Kotresh HR 2015-05-04 18:40:14 UTC
Patch sent: http://review.gluster.org/#/c/10535/

Comment 2 Anand Avati 2015-05-05 13:02:27 UTC
COMMIT: http://review.gluster.org/10535 committed in release-3.7 by Vijay Bellur (vbellur) 
------
commit edfe56dfd8ceb4ef0c160484de04af30e8f5b7df
Author: Kotresh HR <khiremat>
Date:   Tue Apr 14 14:42:46 2015 +0530

    feature/changelog: Capture path for deletes
    
    PROBLEM:
    There is no way to get the path of deleted file if we
    have gfid from changelog since the file is already deleted.
    
    SOLUTION:
    Do a recursive readlink on parent gfid in backend .glusterfs
    path to get the complete path in I/O callpath in changelog
    translator and capture it in callback.
    
    The path captured is relative from the brick root. The field
    separator used is '\0'.
    e.g.,
    ......\0<pgfid>/bname\0<relative-path>\0<next-record>
    
    ADDITIONAL REQUIRED CHANGES:
    
    1. The changelog translator option called "changelog.capture-del-path"
       is introduced to enable or disable the capturing of deleted entry
       path.
       e.g.,
       gluster vol set <vol-name> changelog.capture-del-path on/off
    
       If capture-del-path is disabled, '\0' is captured instead of
       relative path.
       e.g.,
       ......\0<pgfid>/bname\0\0\0<next-record>
    
    2. The minor number in the version of changelog is bumped up from v1.1
       to v1.2.
    
    3. If recursive readlink is failed for some reason, it will capture
       \0 in place of <relative path>.
       e.g.,
       ......\0<pgfid>/bname\0\0\0<next-record>
       (same as when caputre-del-path option is disabled)
    
    4. If bname argument passed to "resolve_pargfid_to_path" function
       is NULL and pargfid is ROOT, "." is returned. This is not the
       case with changelog, where bname is always passed. This is
       applicable to other consumers of "resolve_pargfid_to_path"
       routine.
    
    NOTE:
       Changelog parser should consider the above new changes
       and should parse accordingly.
    
    BUG: 1218383
    Change-Id: I5d89cf4157befd207771f6c0248d2493fbf85832
    Signed-off-by: Kotresh HR <khiremat>
    Reviewed-on: http://review.gluster.org/10288
    Reviewed-on: http://review.gluster.org/10535
    Tested-by: Gluster Build System <jenkins.com>
    Tested-by: NetBSD Build System
    Reviewed-by: Aravinda VK <avishwan>
    Reviewed-by: Vijay Bellur <vbellur>

Comment 3 Niels de Vos 2015-05-14 17:29:35 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-3.7.0, please open a new bug report.

glusterfs-3.7.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] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

Comment 4 Niels de Vos 2015-05-14 17:35:59 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-3.7.0, please open a new bug report.

glusterfs-3.7.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] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

Comment 5 Niels de Vos 2015-05-14 17:38:20 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-3.7.0, please open a new bug report.

glusterfs-3.7.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] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

Comment 6 Niels de Vos 2015-05-14 17:47:12 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-3.7.0, please open a new bug report.

glusterfs-3.7.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] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user