On Jan 11 2017, Chris Davies <[email protected]> wrote: > I have two large (multi-TB) filesystems running on S3QL. One of them > contains a number of large files (several hundred GB). Unfortunately the > filesystem has crashed a number of times over the last few months. Recently > these crashes are becoming more and more frequent - several times a day. I > think I've finally identified the cause, although I don't have a good > resolution. > > It seems that if the filesystem discovers that it is deleting a file, but a > block supposedly belonging to that file does not exist, the filesystem > crashes in a heap. Normally I'd say that the correct resolution would be to > run the filesystem checker in full verification mode, and maybe that's > where I'll end up heading if I can't get a better fix.
What backend are you using? For most sane backends, a regular fsck.s3ql should fix these issues. > However, in this > particular use case I don't think the filesystem should crash. You are right, and it actually should not do that but enter "failsafe" mode instead (file system becomes read-only). Could you please file an issue at https://bitbucket.org/nikratio/s3ql/issues? I'll try to get this fixed in the next release. 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.
