[Gluster-devel] Solving Ctime Issue with legacy files [BUG 1593542]

Kotresh Hiremath Ravishankar khiremat at redhat.com
Mon Jun 17 11:50:09 UTC 2019

Hi All,

The ctime feature is enabled by default from release gluster-6. But as
explained in bug [1]  there is a known issue with legacy files i.e., the
files which are created before ctime feature is enabled. These files would
not have "trusted.glusterfs.mdata" xattr which maintain time attributes. So
on, accessing those files, it gets created with latest time attributes.
This is not correct because all the time attributes (atime, mtime, ctime)
get updated instead of required time attributes.

There are couple of approaches to solve this.

1. On accessing the files, let the posix update the time attributes from
the back end file on respective replicas. This obviously results in
inconsistent "trusted.glusterfs.mdata" xattr values with in replica set.
AFR/EC should heal this xattr as part of metadata heal upon accessing this
file. It can chose to replicate from any subvolume. Ideally we should
consider the highest time from the replica and treat it as source but I
think that should be fine as replica time attributes are mostly in sync
with max difference in order of few seconds if am not wrong.

   But client side self heal is disabled by default because of performance
reasons [2]. If we chose to go by this approach, we need to consider
enabling at least client side metadata self heal by default. Please share
your thoughts on enabling the same by default.

2. Don't let posix update the legacy files from the backend. On lookup cbk,
let the utime xlator update the time attributes from statbuf received

Both approaches are similar as both results in updating the xattr during
lookup. Please share your inputs on which approach is better.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1593542
[2] https://github.com/gluster/glusterfs/issues/473

Thanks and Regards,
Kotresh H R
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20190617/c4cb453c/attachment.html>

More information about the Gluster-devel mailing list