On Sep 26 2016, Chris Davies <[email protected]> wrote:
> I'm really hoping this is a silly, but the code I've been using to call
> s3ql.fsck has been pretty stable for the last three or so S3QL versions.
> Any thoughts please? I've got a crashed filesystem and short of downgrading
> back to 2.19 to see if that might fix the problem I'm not sure where to
> head.
>
> # cd /var/autofs/misc/cache/s3ql && ls -l *Container*
> -rw------- 1 root root 71798784 Sep 24 16:27
> swiftks:=2F=2Fauth.cloud.ovh.net=2FTARGET:Container=2F.db
> -rw-r--r-- 1 root root 0 Sep 24 20:15 swiftks:=2F=2Fauth.cloud.ovh.
> net=2FTARGET:Container=2F.params
It looks like the file system that crashed was not (or at least not
only) the S3QL file system, but the file system holding your
--cachedir. That left you with an empty *.params file. No S3QL version
is going to cope well with that.
You can try to force S3QL to use the *.db file despite the missing
params file (just comment out a few lines in fsck.py), but there's a
good chance that file is corrupted too. Removing the locally cached data
would be the minimum-effort solution, but you'll loose changes made
since the last metadata upload.
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.
