Re: Fw: Deletion of old CHANGELOG files in .glusterfs/changelogs

mabi <mabi@xxxxxxxxxxxxx> · Wed, 05 Apr 2017 13:28:37 -0400

Thanks to all of you for your answers.
I will try the archive tool as recommended by Aravinda.
Just for your information I suppose you are aware that having tons of files such as the CHANGELOGS in one single directory is really sub-optimal. Maybe better would be to have a 2 level hierarchy and store the files using an algorithm to distribute the files among that 2 level hierarchy of sub-directories, especially if there is no archiving of these files by default. Just my two cents ;-)

Cheers

-------- Original Message --------
Subject: Re: [Gluster-users] Fw: Deletion of old CHANGELOG files in .glusterfs/changelogs
Local Time: April 5, 2017 8:44 AM
UTC Time: April 5, 2017 6:44 AM
From: atumball@xxxxxxxxxx
To: Mohammed Rafi K C <rkavunga@xxxxxxxxxx>
mabi <mabi@xxxxxxxxxxxxx>, Gluster Users <gluster-users@xxxxxxxxxxx>

Local Time: March 31, 2017 11:22 PM
UTC Time: March 31, 2017 9:22 PM
From: mabi@xxxxxxxxxxxxx
To: Gluster Users <gluster-users@xxxxxxxxxxx>

Hi,

I am using geo-replication since now over a year on my
          3.7.20 GlusterFS volumes and noticed that the
          CHANGELOG.<TIMESTAMP> in the .glusterfs/changelogs
          directory of a brick never get deleted. I have for example
          over 120k files in one of these directories and it is growing
          constantly.

So my question, does GlusterFS have any mechanism to
          automatically delete old and processed CHANGELOG files? If not
          is it safe to delete them manually?

I will try to answer the question, I'm not an expert in
    geo-replication, So I could be wrong here. I think GlusterFS won't
    delete the changelogs automatically, reason being geo-replication is
    not the author of changelogs, it is just a consumer any other
    application could use changelogs.

+1 for the reasoning.

You can safely delete *all processed* changelogs from actual
    changelogs directory and geo-replication directory. You can look
    into the stime set as the extended attribute on the root to see the
    time which geo-replication last synced.

If georep is the only consumer, you can use Aravinda's tool  to move the files to another dir, and delete them.

Regards,
Amar

_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-users