Bug 1296917 - Tier: Need to overwrite the /var/run/gluster/<vol>/<demotequey> on each cycle
Summary: Tier: Need to overwrite the /var/run/gluster/<vol>/<demotequey> on each cycle
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: tier
Version: rhgs-3.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Dan Lambright
QA Contact: Bala Konda Reddy M
URL:
Whiteboard: tier-migration
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-01-08 12:41 UTC by RajeshReddy
Modified: 2019-12-02 12:14 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-15 10:28:32 UTC
Embargoed:


Attachments (Terms of Use)

Description RajeshReddy 2016-01-08 12:41:08 UTC
Description of problem:
=========
Tier: Need to overwrite the /var/run/gluster/<vol>/<demotequey> on each cycle 

Version-Release number of selected component (if applicable):
============
glusterfs-server-3.7.5-15


How reproducible:


Steps to Reproduce:
===========
1. After querying the DB placing all eligible files (promoted/demoted)   /var/run/gluster/<vol>/<demotequey>, we are processing all the entries in the file and then querying the DB, though multiple cycles passed in between 
2.
3.

Actual results:


Expected results:
=========
On each cycle need to query the DB and overwrite the /var/run/gluster/<vol>/<demotequey> and should not process the existing since the entries are stale 


Additional info:

Comment 3 RajeshReddy 2016-01-11 06:12:56 UTC
I created lot of files and deleted them but tierd keep on trying to demote files which were deleted and able to see lot of error messages in the log saying lookup of given file is failed and seeing the same messages on the log after couple of hours too 

so i am thinking we are not overwriting the /var/run/gluster/<vol>/<demotequey> after each cycle

Comment 4 Nithya Balachandran 2016-01-11 06:19:59 UTC
The query files are generated from the database. If the database has not been modified, the query will generate the same results each time and you will end up with the same entries in the query file.

You can verify whether the files is being overwritten by deleting the .err file. The next failed cycle should rename the new query file to .err file. You can also delete the query file and see if it is being recreated in the next cycle(It should).

If the above is true, this is not a bug.

Comment 5 RajeshReddy 2016-01-14 11:29:44 UTC
After deleting the .err file it is not getting created after next cycle

Comment 6 Nithya Balachandran 2016-01-15 15:30:03 UTC
Did the promotions/demotions fail? The .err file is created only when there is a failure.

The .err file deletion test was suggested specifically for the setup on which demotion failures were reported. If the migration is successful, a better test would be to check the size of the file between cycles.

Comment 8 Nithya Balachandran 2016-07-15 10:28:32 UTC
This is already done as part of tiering. Closing this as WorkForMe.


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