[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ceph-dev
Subject:    Re: Data log timestamps
From:       Casey Bodley <cbodley () redhat ! com>
Date:       2023-04-24 20:02:14
Message-ID: CAF-p1-+KRGhW9n5F4cZ2E+PFsWU01ceejVL7zvtmZTXYGQoQ2w () mail ! gmail ! com
[Download RAW message or body]

On Mon, Apr 24, 2023 at 3:36 PM Yixin Jin <yjin77@yahoo.ca> wrote:
> 
> Hi folks,
> 
> I noticed that rgw data logs are generated with a timestamp (cls_log_entry in \
> cls_log_types.h), which seems to be used to ensure a certain order among all logs \
> from peers in a zonegroup during sync. Since machine clocks are not perfectly in \
> sync and using timestamps from different machines may lead to the different order \
> than what truly has happen, how does ceph/rgw protect itself against this issue? \
> Originally, I thought it gets a monotonic ID from the master zone or using master \
> zone's timestamp. It doesn't seem to be the case or did I read the code wrong? 
> Thanks,
> Yixin
> _______________________________________________
> Dev mailing list -- dev@ceph.io
> To unsubscribe send an email to dev-leave@ceph.io

the datalog timestamps are not compared across source zones like this.
data sync just processes the stream of datalog events from a given
source zone and spawns bucket sync for each one

timestamps only come into play when replicating objects. if a local
copy of the destination object already exists, the GET request to
fetch it will include the local object's mtime in an If-Modified-Since
header. the object will be only be transferred if the source zone has
a more recent copy

you're right that clock skew between zones may not preserve the true
order of uploads, but this strategy at least guarantees that all zones
will converge on the same object upload with the highest mtime
_______________________________________________
Dev mailing list -- dev@ceph.io
To unsubscribe send an email to dev-leave@ceph.io


[prev in list] [next in list] [prev in thread] [next in thread]