Hi Jeff, When replying to emails on this list, please do not put your reply above the quoted text, and do not quote the entire message you're answering to. This makes it unnecessarily hard for other readers to understand the context of your email. Instead, please cut quoted parts that are not relevant to your reply, and insert your responses right after the points you're replying to (as I have done below). Thanks!
Jeff Bogatay <[email protected]> writes: > Sorry, > > "The Store" = the backend/remote storage. In this case it's Amazon > S3/USA. > > With respect to fragility, I was simply referring to forgetting to > umount the remote filesystem (or power failure, or... whatever). I see > links to people who leave remote filesystems mounted (via > upstart/systemd) and if a reboot without umount can corrupt the > filesystem to the point it's unmountable, and it's unfsckable -- > that's an issue. No, this should not happen. If you reboot without unmounting, you will need to run fsck.s3ql, but after things should just work you. I'm actually testing this regularly myself. So something is special about your system. > The main backup filesystem is still unfsckable. Here is the console > output instead of the log. > > Using cached metadata. > Remote metadata is outdated. > Checking DB integrity... [...] > Compressing and uploading metadata... > Uncaught top-level exception: [..] > File "/usr/lib/python3.4/site-packages/dugong/__init__.py", line 619, > in _co_send > len_ = self._sock.send(buf) > File "/usr/lib/python3.4/ssl.py", line 679, in send > v = self._sslobj.write(data) > OSError: [Errno 14] Bad address (the formatting of the output is still messed up, in the future please attach it as a separate file if your mailclient insists on reformatting it) What this error means is that your file system is in good condition, but when fsck.s3ql tries to upload a "clean" marker to the storage server, the operating system signals an error with the TCP/IP connection. Are you able to try fsck'ing this file system from another computer? If you are comfortable doing that, could you check if you get the same error if you run fsck.s3ql with --backend-options no-ssl? 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.
