On Sat, Feb 20, 2021 at 01:24:16PM +0000, Graham Cobb wrote:
Package: s3ql Version: 3.7.0+dfsg-2 Severity: importantDear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** After upgrading s3ql from 3.3.2+dfsg-1 I suffered from bug #982381 (trio) so I tried manually installing trio 0.15 (as mentioned in that thread). Although it allowed some files to be created, any long or complex operation (such as a backup, or even an `rm -rf` of a large directory) cause a 'Software caused connection abort' error followed by enormous numbers of 'Transport endpoint is not connected' errors. In case it was some transient network problem, I used fsck.s3ql to fix the filesystem and retried - same errors. And the same errors if I (fsck again and) just try a `rm -rf` on a large directory. I then tried installing trio 0.18. Same problem. Mounting is working. fsck is working. Simple file operations are working. But heavy load causes 'Software caused connection abort'. Completely repeatable. The following commands reproduce the problem for me: cd /mnt/mountpoint count=100 mkdir testdir ; for f in `seq 1 $count` ; do mkdir testdir/$f ; dd if=/dev/urandom bs=1000 count=1 of=testdir/$f/test status=none ; done rm -rf testdir umount /mnt/mountpoint With the count at 100 the problem occurs when the unmount happens. If the count is increased to 2000 the problem occurs during the run. This is using the S3 backend. By the way, this workload has been working for many years with no problems, and was working with 3.3.2+dfsg-1 before I decided to try testing 3.7.0+dfsg-2.
Could you please follow-up with your ~/.s3ql/mount.log log about the error? -- Francesco P. Lovergine
