[Gluster-devel] Cloudsync with AFR

[Kotresh Hiremath Ravishankar]

Hi Anuradha,

To enable the c-time (consistent time) feature. Please enable following two
options.

gluster vol set <volname> utime on
gluster vol set <volname> ctime on

Thanks,
Kotresh HR

On Fri, Sep 14, 2018 at 12:18 PM, Rafi Kavungal Chundattu Parambil <
rkavunga at redhat.com> wrote:

> Hi Anuradha,
>
> We have an xlator to provide consistent time across replica set. You can
> enable this xlator to get the consistent mtime,atime, ctime.
>
>
> Regards
> Rafi KC
>
> ----- Original Message -----
> From: "Anuradha Talur" <atalur at commvault.com>
> To: gluster-devel at gluster.org
> Cc: amarts at redhat.com, "Ram Ankireddypalle" <areddy at commvault.com>,
> "Sachin Pandit" <sachinpandit at commvault.com>
> Sent: Thursday, September 13, 2018 7:19:26 AM
> Subject: [Gluster-devel] Cloudsync with AFR
>
>
>
> Hi,
>
> We recently started testing cloudsync xlator on a replica volume.
> And we have noticed a few issues. We would like some advice on how to
> proceed with them.
>
>
>
> 1) As we know, when stubbing a file cloudsync uses mtime of files to
> decide whether a file should be truncated or not.
>
> If the mtime provided as part of the setfattr operation is lesser than the
> current mtime of the file on brick, stubbing isn't completed.
>
> This works fine in a plain distribute volume. B ut i n case of a replica
> volume, the mtime could be different for the files on each of the replica
> brick.
>
>
> During our testing we came across the following scenario for a replica 3
> volume with 3 bricks:
>
> We performed `setfattr -n "trusted.glusterfs.csou.complete" -v m1 file1`
> from our gluster mount to stub the files.
> It so happened that on brick1 this operation succeeded and truncated file1
> as it should have. But on brick2 and brick3, mtime found on file1
> was greater than m1, leading to failure there.
>
> From AFR's perspective this operation failed as a whole because quorum
> could not be met. But on the brick where this setxattr succeeded, truncate
> was already performed. So now we have one of the replica bricks out of sync
> and AFR has no awareness of this. This file needs to be rolled back to its
> state before the
>
>
> setfattr.
>
> Ideally, it appears that we should add intelligence in AFR to handle this.
> How do you suggest we do that?
>
>
> The case is also applicable to EC volumes of course.
>
> 2) Given that cloudsync depends on mtime to make the decision of
> truncating, how do we ensure that we don't end up in this situation again?
>
> Thanks,
> Anuradha
> ***************************Legal Disclaimer***************************
> "This communication may contain confidential and privileged material for
> the
> sole use of the intended recipient. Any unauthorized review, use or
> distribution
> by others is strictly prohibited. If you have received the message by
> mistake,
> please advise the sender by reply email and delete the message. Thank
> you."
> **********************************************************************
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>



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