On Sunday, September 14, 2025 at 1:37:12 PM UTC-4 Nikolaus Rath wrote:
On Sat, 13 Sep 2025, at 18:32, 'Joseph Maher' via s3ql wrote:
> Just thought I'd report the following crash using 5.4 with the additional
> patch for setting metadata-backup-interval=0. The error message is long,
> so I have posted at the end pf this email. I don't know what it means, it
> could be a network problem, but I didn't notice any other connection
> problems with this machine.
[...]
> | File "/usr/lib/python3/dist-packages/s3ql/backends/gs.py", line
> 461, in _write_fh
> | resp = self._do_request(
> | 'POST',
> | ...<3 lines>...
> | body=BodyFollowing(body_size),
> | )
> | File "/usr/lib/python3/dist-packages/s3ql/backends/gs.py", line
> 606, in _do_request
> | resp = self.conn.read_response()
> | File "/usr/lib/python3/dist-packages/s3ql/http.py", line 769, in
> read_response
> | return eval_coroutine(self.co_read_response())
> | File "/usr/lib/python3/dist-packages/s3ql/http.py", line 1429, in
> eval_coroutine
> | next(it)
> | ~~~~^^^^
> | File "/usr/lib/python3/dist-packages/s3ql/http.py", line 787, in
> co_read_response
> | raise StateError('Previous response not read completely')
> | s3ql.http.StateError: Previous response not read completely
Thanks for reporting this. This is a bug in S3QL. Unfortunately it will be
very hard to track down, since the actual error happened *before* the
exception was raised (the exception just detects that something must have
gone wrong before), and because it's apparently rather rare (this is the
first such report in many years).
It'd be great if you could file it at https://github.com/s3ql/s3ql/issues
so we can keep track of it, but it's unlikely to be fixed until we can find
a way to reproduce this.
> Running fsck.s3ql --force on this filesystem takes about 4 days, is there
> a way to avoid doing this?
Which steps take the longest? Depending on that, --fast may or may not
help.
Best,
-Nikolaus
I've filed a report at https://github.com/s3ql/s3ql/issues/392
I'm currently mounting the file system with a fairly large cache size, so
it tends to have a fairly large number of dirty blocks (about 1 million).
I will try mounting with a much smaller cache size in future and see if
that helps...
Joseph
--
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].
To view this discussion visit
https://groups.google.com/d/msgid/s3ql/a942d119-1b71-476c-a25c-5422688c3595n%40googlegroups.com.
