Warren Daly <[email protected]> writes: >> >> > Also reading up on how to not ignore local metadata? >> >> There is no easy way to do that. One way is to change fsck.py to pretend >> that the remote sequence number is zero. The following change will do >> that (make sure to revert it after use!): >> >> diff --git a/src/s3ql/fsck.py b/src/s3ql/fsck.py >> --- a/src/s3ql/fsck.py >> +++ b/src/s3ql/fsck.py >> @@ -1084,7 +1084,8 @@ >> raise QuietError(str(exc)) >> >> cachepath = get_backend_cachedir(options.storage_url, >> options.cachedir) >> - seq_no = get_seq_no(backend) >> + log.warning("**WARNING** IGNORING REMOTE METADATA") >> + seq_no = 0 >> db = None >> >> if os.path.exists(cachepath + '.params'): >> > > Well this is the log file before the reboot. it would appear that these > logs indicate that I should just use the remote metadata (and in turn allow > deletion of Spurious objects)?
I don't follow. Do you mean the logfile that you quoted further down, where it says that mount.s3ql refused to update the remote metadata? Here is how I think your situation may have come about: - You mounted the file system on system A a long time ago - You then tried to mount it on system B, but got an error message that the system is still mounted elsewhere - You then ran fsck.s3ql on system B and told it to continue despite the lack of up-to-date metadata. - Now everything seemed working on system B. - Ever since then, however, system A (where the file system was still mounted) did not upload its metadata, because it detected that a "newer" version of the metadata has been uploaded by system B. This is why you do not have any recent metadata backups. - Now that you unmounted system A, you have a problem. The local metadata copy appears older than the remote metadata, but it was actually modified more recently. The correct course of action depends on which system you did the more important changes. If you only ran a brief fsck.s3ql on system B at some indeterminate point in the past, you should use the local metadata from system A (even though fsck.s3ql claims its outdated). If you mounted the file system on system B and stored important data there, you may want to use the remote metadata (but it that case will loose everything you did on system A). > The whole reason I have started this thread is anxiousness when it reports > deletion of so many "Spurious objects". To put things in perspective there > is about 360,000 files on the system. Fsck processes about 600,000 objects. > Then begins to delete "Spurious objects" one by one. I would prefer if it > moved them to Lost & Found or I could even move them to a specific > folder. Yeah, that's a planned feature: https://bitbucket.org/nikratio/s3ql/issue/30/fscks3ql-should-save-orphaned-objects-to Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- You received this message because you are subscribed to the Google Groups "s3ql" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
