Unmounting leaves metadata DB locked

[GoogleCodeExporter]

Hello,

I am running s3ql 1.12 on Ubuntu 12.04 Lucid. I recently performed a test where 
I created a new s3ql filesystem on an Amazon S3 bucket in the Oregon region:
# mkfs.s3ql s3://mybucket
Enter backend login: 
Enter backend password: 
_do_request(): redirected to 
http://mybucket.s3-us-west-2.amazonaws.com/s3ql_passphrase
Before using S3QL, make sure to read the user's guide, especially
the 'Important Rules to Avoid Loosing Data' section.
_do_request(): redirected to 
http://wccimages.s3-us-west-2.amazonaws.com/s3ql_metadata
Encountered IncompleteRead exception (IncompleteRead(0 bytes read)), retrying 
call to Backend.lookup...
Purging existing file system data..
Please note that the new file system may appear inconsistent
for a while until the removals have propagated through the backend.
...

I'm not sure if the IncompleteRead exception is a concern or not. This only 
seems to occur if I select a region other than US Standard. After, I mount the 
filesystem:
# mount.s3ql --allow-other --debug fuse s3://mybucket /mnt/test

This works fine the first time. I then rsync some data (less than 20MB) to the 
s3ql filesystem and then unmount it. After doing so, any attempt to mount it 
again results in a "BusyError: BusyError: database is locked" error. I have 
attached some logging debug output as well. What other information can I 
provide to help diagnose why the database is being locked?

Thanks!

Andrew

Original issue reported on code.google.com by andrew.s...@gmail.com on 3 Dec 2012 at 6:36

Attachments:

• s3ql_database_locked.log

[GoogleCodeExporter]

The IncompleteRead message is harmless.

My guess is that you still have some mount.s3ql zombie process around. What 
does 
"ps ax | grep mount.s3ql" return?

If that's the problem, then restarting your system should fix it.

Are you able to reproduce this problem reliably?

Original comment by Nikolaus@rath.org on 6 Jan 2013 at 1:35

• Changed title: Unmounting leaves metadata DB locked
• Changed state: NeedsInfo
• Added labels: Type-Bug

[GoogleCodeExporter]

Thanks for the help. Indeed, another mount.s3ql process exists, and is holding 
up the database lock. Is it possible that this process is still finishing 
syncing data to the cloud storage? Is there a way to track when data is synced 
(e.g. an equivalent of calling "sync" with this fs)? If it is just finishing 
syncing the data, I can wait for it, but running an strace on it doesn't show 
any activity.

I can reproduce this problem reliably.

Original comment by andrew.s...@gmail.com on 6 Jan 2013 at 4:18

[GoogleCodeExporter]

Are you using umount.s3ql to unmount the file system? That should block until 
all data has been synchronized.

Do you need to perform any activity during the first mount for the problem to 
occur, or does it happen even if you don't access the file system at all?

When you run strace on the process from the beginning, what are the last lines 
of output before it hangs?

Could you run the first mount.s3ql call with --debug all, unmount it (using 
umount.s3ql), confirm that the mount.s3ql process is still running, and then 
attach mount.log to this issue?

Thanks!

Original comment by Nikolaus@rath.org on 13 Jan 2013 at 9:02

[GoogleCodeExporter]

Thanks for your help regarding this issue. I haven't been able to reproduce 
with my s3ql mount for several weeks now. If it appears again I will post the 
debug you requested.

Thanks!

Original comment by andrew.s...@gmail.com on 8 Feb 2013 at 6:33

[GoogleCodeExporter]

I'll close this bug for now. Please feel free to reopen if the problem appears 
again.

Thanks for reporting this.

Original comment by Nikolaus@rath.org on 12 Mar 2013 at 3:10

• Changed state: Invalid