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.

Reply via email to