Re: Geo-replication fills up inode by saving processed changelog files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/11/2014 11:40 AM, Aravinda wrote:
Hi,


While geo-replication is running it keeps processed changelog files in
$WORKING_DIR/.processed or $WORKING_DIR/.history/.processed. These
changelog files are useful for debugging processed changelogs. But these
changelogs eats up the space/available inodes. The changelog files saved
in processed directory is duplicate of changelogs available in brick
backend(Difference is in the format, changelogs in processed dir are
parsed and human readable).

Do we consume 2 inodes per changelog - one in $WORKING_DIR and another in the brick? If yes, how do we avoid consuming inodes in the filesystem that contains the brick?


How about keeping only the reference to changelog file after processed.
For debugging their will be additional step to look for changelog from
backend($BRICK/.glusterfs/changelogs) using this reference.

After syncing data to slave(In geo-replication)
echo $changelog_filename >> $WORKING_DIR/.processed_files
rm $WORKING_DIR/.processing/$changelog_filename

We need to modify `gf_changelog_done` and `gf_history_changelog_done`
functions in
libgfchangelog($GLUSTER_SRC/xlators/features/changelog/lib/src)

Any thoughts?

Archiving retired changelogs may be an option. What would be the scenario when there are multiple changelog consumers (apart from geo-replication)?

-Vijay


_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux