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/920ef964311a61fcc6c0d6671b77...
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@vanderster.com> Sent: 15 October 2020 12:44 To: ceph-users <ceph-users@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/920ef964311a61fcc6c0d6 671b77ffe98522863d _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@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.
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@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@vanderster.com> Sent: 15 October 2020 12:44 To: ceph-users <ceph-users@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/920ef964311a61fcc6c0d6 671b77ffe98522863d _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@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.
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@vanderster.com> Sent: 23 March 2021 11:24 To: Byrne, Thomas (STFC,RAL,SC) <tom.byrne@stfc.ac.uk> Cc: ceph-users <ceph-users@ceph.io>; Theofilos Mouratidis <t.mour@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@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@vanderster.com> Sent: 15 October 2020 12:44 To: ceph-users <ceph-users@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]
d6 671b77ffe98522863d _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@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
https://github.com/ceph/ceph/pull/24023/commits/920ef964311a61fcc6c0 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.
participants (2)
-
Byrne, Thomas (STFC,RAL,SC)
-
Dan van der Ster