I've just found the mount.log file . Sorry for not included this
information earlier.
Which has all the backtraces in it .
That doesn't surprise me givent he exception:-
apsw.CorruptError: CorruptError: database disk image is malformed
Here are a couple of traecbacks:-
Thread-7 (name)s.excepthook: Uncaught top-level exception:
Traceback (most recent call last):
File "/usr/lib/s3ql/s3ql/block_cache.py", line 434, in _do_upload
self.db.execute('UPDATE objects SET size=? WHERE id=?', (obj_size,
obj_id))
File "/usr/lib/s3ql/s3ql/database.py", line 98, in execute
self.conn.cursor().execute(*a, **kw)
File "src/cursor.c", line 231, in resetcursor
apsw.CorruptError: CorruptError: database disk image is malformed
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/s3ql/s3ql/mount.py", line 66, in run_with_except_hook
run_old(*args, **kw)
File "/usr/lib/python3.4/threading.py", line 868, in run
self._target(*self._args, **self._kwargs)
File "/usr/lib/s3ql/s3ql/block_cache.py", line 404, in _upload_loop
self._do_upload(*tmp)
File "/usr/lib/s3ql/s3ql/block_cache.py", line 463, in _do_upload
(obj_id,))
File "/usr/lib/s3ql/s3ql/database.py", line 98, in execute
self.conn.cursor().execute(*a, **kw)
File "src/cursor.c", line 231, in resetcursor
apsw.CorruptError: CorruptError: database disk image is malformed
But if I scroll up the log file I see it starts a little differently:-
CommitThread (name)s.excepthook: Uncaught top-level exception:
Traceback (most recent call last):
File "/usr/lib/s3ql/s3ql/database.py", line 143, in get_row
row = next(res)
StopIteration
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/s3ql/s3ql/block_cache.py", line 531, in upload
block_id = self.db.get_val('SELECT id FROM blocks WHERE hash=?',
(hash_,))
File "/usr/lib/s3ql/s3ql/database.py", line 127, in get_val
return self.get_row(*a, **kw)[0]
File "/usr/lib/s3ql/s3ql/database.py", line 145, in get_row
raise NoSuchRowError()
s3ql.database.NoSuchRowError: Query produced 0 result rows
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/s3ql/s3ql/block_cache.py", line 535, in upload
obj_id = self.db.rowid('INSERT INTO objects (refcount, size) VALUES(1,
-1)')
File "/usr/lib/s3ql/s3ql/database.py", line 104, in rowid
self.conn.cursor().execute(*a, **kw)
File "src/cursor.c", line 231, in resetcursor
apsw.FullError: FullError: database or disk is full
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/s3ql/s3ql/mount.py", line 66, in run_with_except_hook
run_old(*args, **kw)
File "/usr/lib/s3ql/s3ql/mount.py", line 795, in run
self.block_cache.upload(el)
File "/usr/lib/s3ql/s3ql/block_cache.py", line 573, in upload
self._unlock_obj(obj_id, noerror=True)
UnboundLocalError: local variable 'obj_id' referenced before assignment
That would be clear about something running out of diskspace, - I assume
(because I was aware of a limit on S3 accounts)
that is a local filesystem. Any idea which one? My guess would be the
metadata cache, but that seem find at the moment.
Can you shed any light on it ; or give be guidance on metadata sizing ?
On Wednesday, September 7, 2016 at 12:13:48 PM UTC+1, Roger Gammans wrote:
>
> Hi all,
>
> I'm trying to use s3ql for multi terabyte backup, which has lot of
> duplication at the block level ,
>
> But I'm finding that since I've changed to using a machine ith debian
> jessie installed that I'm getting to the situation where I get the
> "Transport endpoint is not connected", error messages, the mount.s3ql if
> still running on the most recent time
> this has happened but I'm not 100% sure that has always been the case.,
> however I haven't capture a backtrace.
>
> The system was reliable when I was running debian wheezy and using S3ql
> 1.11, but the jessie machine has 2.11.
>
> Is this a known issue with 2.11 ? - is it worth upgrading to the latest ?
> I'm hesistant because this is a production server and I normally prefer
> distribution packages, on production.
>
--
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.