Someone correct me if I'm saying something stupid but from what I see in the code, there is a check each time to make sure rctime doesn't go back. Which seems logical to me because otherwise you would have to go through all the children to determine the correct ctime. I don't have the impression that a scrub on the fs will solve the problem. Apart from creating a script that manipulates the metas (dangerous) or the restoration, I don't have much of an idea. (except [joke] to wait until 2040) ________________________________________________________ Cordialement, *David CASIER* ________________________________________________________ Le ven. 20 oct. 2023 à 11:04, MARTEL Arnaud <arnaud.martel@cea.fr> a écrit :
Hi all,
I have some troubles with my backup script because there are few files, in a deep sub-directory, with a creation/modification date in the future (for example: 2040-02-06 18:00:00). As my script uses the ceph.dir.rctime extended attribute to identify the files and directories to backup, it now browses and sync a lot of unchanged sub-directories… I tried a lot of things, including remove and recreate the files so they have now the current datetime, but rctime is never updated. Even when I remove the last directory (ie: the one where the files are located), rctime is not updated for the parent directories.
Has someone a trick to reset rctime to current datetime (or any other solution to remove this inconsistent value of rctime) with quincy (17.2.6) ?
Regards, Arnaud _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io