Bug 1207028 - [Backup]: User must be warned while running the 'glusterfind pre' command twice without running the post command
Summary: [Backup]: User must be warned while running the 'glusterfind pre' command twi...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: glusterfind
Version: mainline
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
Assignee: Aravinda VK
QA Contact: bugs@gluster.org
URL:
Whiteboard:
Depends On:
Blocks: qe_tracker_everglades 1218166 1224072
TreeView+ depends on / blocked
 
Reported: 2015-03-30 05:48 UTC by Sweta Anandpara
Modified: 2016-06-16 12:45 UTC (History)
5 users (show)

Fixed In Version: glusterfs-3.8rc2
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1218166 1224072 (view as bug list)
Environment:
Last Closed: 2016-06-16 12:45:56 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Sweta Anandpara 2015-03-30 05:48:49 UTC
Description of problem:

As per the sequence of steps to be followed, 'glusterfind create' is to be followed with a 'pre' and a 'post' to generate the list of changed files, and to update the timestamp to the latest one, respectively. There would be times when the admin might forget to run the 'post' step, thereby forgetting to update the timestamp, resulting in an incorrect list of changed files.

When any 'glusterfind pre' command is given, we could have a check if the 'glusterfind post' command has been executed or not.. by simply checking the existence of 'status.pre' file in the $SESSION_DIR location, or by any other means. A confirmation message to the user letting him know that the 'glusterfind post' command is not run, and would he still like to continue, would help.

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

Glusterfs upstream nightly glusterfs-3.7dev-0.777.git2308c07.el6.x86_64

How reproducible: 

Easily.
This would particularly happen if the user chooses to NOT use the wrapper script that we are going to provide, and goes ahead with the CLI commands


Steps to Reproduce:
1. Have a glusterfs volume, create a session using 'glusterfind create'
2. Create new files in the volume
3. Run 'glusterfind pre' command
4. Check the output file if it has a mention of files created in step2
5. Create more new files in the volume
6. Again run 'glusterfind pre' command
5. Check the output file if it has a mention of files created in step2 as well as step5


Actual results:

Step6 should ask the user for a confirmation stating something like this:

"Glusterfind post command has not been run after running the pre command last time. This would result in an aggregated list of changed files. Would you still like to continue? Y/N "

Expected results:

No warning is given

Additional info:

[root@dhcp43-140 ~]# rpm -qa | grep glusterfs
glusterfs-regression-tests-3.7dev-0.777.git2308c07.el6.x86_64
glusterfs-3.7dev-0.777.git2308c07.el6.x86_64
glusterfs-extra-xlators-3.7dev-0.777.git2308c07.el6.x86_64
glusterfs-resource-agents-3.7dev-0.777.git2308c07.el6.noarch
glusterfs-debuginfo-3.7dev-0.777.git2308c07.el6.x86_64
glusterfs-libs-3.7dev-0.777.git2308c07.el6.x86_64
glusterfs-api-3.7dev-0.777.git2308c07.el6.x86_64
glusterfs-devel-3.7dev-0.777.git2308c07.el6.x86_64
glusterfs-cli-3.7dev-0.777.git2308c07.el6.x86_64
glusterfs-server-3.7dev-0.777.git2308c07.el6.x86_64
glusterfs-geo-replication-3.7dev-0.777.git2308c07.el6.x86_64
glusterfs-rdma-3.7dev-0.777.git2308c07.el6.x86_64
glusterfs-ganesha-3.7dev-0.777.git2308c07.el6.x86_64
glusterfs-fuse-3.7dev-0.777.git2308c07.el6.x86_64
glusterfs-api-devel-3.7dev-0.777.git2308c07.el6.x86_64
[root@dhcp43-140 ~]#

Comment 1 Aravinda VK 2015-04-07 08:36:02 UTC
Pre command always gets the latest information when we run more than once. Pre command will not update the session unless post command is called. So when we run pre command next time without post it gets latest information from previous session.

Since this is not feature blocker, we can move out of 3.7 tracker.

Comment 2 Sweta Anandpara 2015-04-07 10:07:53 UTC
>> Pre command always gets the latest information when we run more than once

Does it not compare the time stamp in the status file (in $SESSION_DIR), and compare the mtime/ctime of files wrt to *that* timestamp? 

In the case where the customer has run pre command, supplied the outfile to the backup tool and forgotten to run the post command - the next pre command is going to get the list of files wrt to the time stamp present in the status file. And this will result in an outfile which will have one *big* list of files - which includes all the changed-files already backed up from the previously run pre command as well.

Comment 3 Aravinda VK 2015-04-07 10:15:46 UTC
(In reply to Sweta Anandpara from comment #2)
> >> Pre command always gets the latest information when we run more than once
> 
> Does it not compare the time stamp in the status file (in $SESSION_DIR), and
> compare the mtime/ctime of files wrt to *that* timestamp? 
> 
> In the case where the customer has run pre command, supplied the outfile to
> the backup tool and forgotten to run the post command - the next pre command
> is going to get the list of files wrt to the time stamp present in the
> status file. And this will result in an outfile which will have one *big*
> list of files - which includes all the changed-files already backed up from
> the previously run pre command as well.

pre and post commands will be configured as hook script in backup utilities, so will get executed automatically.

If post command is failed or not run, that means some failure in consuming the file generated from pre command. So when we run next time it should pick those changes again since it is not completed last time.

Comment 4 Aravinda VK 2015-04-27 04:34:17 UTC
This patch addresses this issue. Moving this to POST.
http://review.gluster.org/#/c/10320/

Comment 5 Anand Avati 2015-04-28 09:13:49 UTC
REVIEW: http://review.gluster.org/10418 (tools/glusterfind: New option to pre --regenerate-outfile) posted (#1) for review on master by Aravinda VK (avishwan)

Comment 6 Anand Avati 2015-04-30 10:27:08 UTC
REVIEW: http://review.gluster.org/10418 (tools/glusterfind: New option to pre --regenerate-outfile) posted (#2) for review on master by Aravinda VK (avishwan)

Comment 7 Anand Avati 2015-05-02 13:41:06 UTC
REVIEW: http://review.gluster.org/10418 (tools/glusterfind: New option to pre --regenerate-outfile) posted (#3) for review on master by Aravinda VK (avishwan)

Comment 8 Anand Avati 2015-05-04 09:27:37 UTC
COMMIT: http://review.gluster.org/10418 committed in master by Vijay Bellur (vbellur) 
------
commit 20353cc323704292753ea6b7b0034362109fef76
Author: Aravinda VK <avishwan>
Date:   Tue Apr 28 14:40:27 2015 +0530

    tools/glusterfind: New option to pre --regenerate-outfile
    
    When pre command is run twice, it overwrites the outfile.
    Now pre command will fail when executed twice. To force the
    regeneration use --regenerate-outfile
    
    Change-Id: I0cf7a139522812ece4decdfbcba667a05ce5c35e
    Signed-off-by: Aravinda VK <avishwan>
    BUG: 1207028
    Reviewed-on: http://review.gluster.org/10418
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Kotresh HR <khiremat>

Comment 9 Aravinda VK 2015-05-27 08:08:58 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.

Comment 10 Niels de Vos 2016-06-16 12:45:56 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.8.0, please open a new bug report.

glusterfs-3.8.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://blog.gluster.org/2016/06/glusterfs-3-8-released/
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user


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