Thanks Dan (and Theo),
Ah, that's a shame, that PR looks good to me, and would certainly allow me to restore
some order to our futuristic rctimes (and use them for backup purposes). I'm not sure
if there is there anything I can do to help get it merged, but happy to help if
possible.
Cheers,
Tom
-----Original Message-----
From: Dan van der Ster <dan(a)vanderster.com>
Sent: 23 March 2021 11:24
To: Byrne, Thomas (STFC,RAL,SC) <tom.byrne(a)stfc.ac.uk>
Cc: ceph-users <ceph-users(a)ceph.io>io>; Theofilos Mouratidis
<t.mour(a)cern.ch>
Subject: Re: [ceph-users] fixing future rctimes
Hi Tom,
Teo prepared a PR but we didn't get feedback:
https://github.com/ceph/ceph/pull/37938
--- dan
On Tue, Mar 23, 2021 at 11:55 AM Byrne, Thomas (STFC,RAL,SC)
<tom.byrne(a)stfc.ac.uk> wrote:
Hi Dan,
Did you get anywhere with fixing your future rctimes, or understanding why
you were getting them in the first place? I think we've run into this
problem,
future rctimes with no associated future subdir/item.
The other similarity is the future rctimes always seem to end in .090,
compared to more decimal places for the correct rctimes. I understand the
'09' prefix was a bug, so I assume that means there was no nanosecond
component reported for the future rctimes. Not sure whether this points to
something other than clients with wonky clocks, but it's odd.
e.g. these dirs. were all created and filled by the same client, sequentially:
]# getfattr -n ceph.dir.rctime *
# file: 0001
ceph.dir.rctime="1614858289.09988958262"
# file: 0002
ceph.dir.rctime="2140551942.090"
# file: 0003
ceph.dir.rctime="1614876495.09878190535"
Thanks,
Tom
> -----Original Message-----
> From: Dan van der Ster <dan(a)vanderster.com>
> Sent: 15 October 2020 12:44
> To: ceph-users <ceph-users(a)ceph.io>
> Subject: [ceph-users] fixing future rctimes
>
> Hi all,
>
> We have a few subdirs with an rctime in the future.
>
> # getfattr -n ceph.dir.rctime session # file: session
> ceph.dir.rctime="2576387188.090"
>
> I can't find any subdir or item in that directory with that rctime,
> so I presume that there was previously a file and that rctime cannot
> go backwards [1] Is there any way to fix these rctimes so they show
> the latest ctime of the subtree?
>
> Also -- are we still relying on the client clock to set the rctime /
> ctime of a file? Would it make sense to limit ctime/rctime for any
> update to the current time on the MDS ?
>
> Best Regards,
>
> Dan
>
> [1]
>
https://github.com/ceph/ceph/pull/24023/commits/920ef964311a61fcc6c0
d6
671b77ffe98522863d
_______________________________________________
ceph-users mailing list -- ceph-users(a)ceph.io To unsubscribe send an
email to ceph-users-leave(a)ceph.io
This email and any attachments are intended solely for the use of the
named recipients. If you are not the intended recipient you must not use,
disclose, copy or distribute this email or any of its attachments and should
notify the sender immediately and delete this email from your system. UK
Research and Innovation (UKRI) has taken every reasonable precaution to
minimise risk of this email or any attachments containing viruses or malware
but the recipient should carry out its own virus and malware checks before
opening the attachments. UKRI does not accept any liability for any losses or
damages which the recipient may sustain due to presence of any viruses.
Opinions, conclusions or other information in this message and attachments
that are not related directly to UKRI business are solely those of the author
and do not represent the views of UKRI.
>
This email and any attachments are intended solely for the use of the named recipients. If
you are not the intended recipient you must not use, disclose, copy or distribute this
email or any of its attachments and should notify the sender immediately and delete this
email from your system. UK Research and Innovation (UKRI) has taken every reasonable
precaution to minimise risk of this email or any attachments containing viruses or malware
but the recipient should carry out its own virus and malware checks before opening the
attachments. UKRI does not accept any liability for any losses or damages which the
recipient may sustain due to presence of any viruses. Opinions, conclusions or other
information in this message and attachments that are not related directly to UKRI business
are solely those of the author and do not represent the views of UKRI.