On Thu, 4 Dec 2014, Nikolaus Rath wrote:
On 12/03/2014 11:44 PM, Shannon Dealy wrote:
the file system still hangs (or the next time it hangs), could you
follow the instructions at
https://bitbucket.org/nikratio/s3ql/wiki/Providing%20Debugging%20Info to
obtain a Python stacktrace, and attach it to this issue?
This time the file system didn't hang until I attempted to unmount it.
Attached are two log files with the mount and stack trace information.
This looks odd. Did you issue both "setfattr -n fuse_stacktrace" *and*
"kill -s USR1" commands?
Yes, I didn't realize that the setfattr command was being used to trigger
a one time event, I thought it was more like turning on a debug mode with
extra info.
If I am not mixing things up, I believe that initial setfattr was run
right after mounting the file system, and the "kill -s USR1" was run when
the file system was hung during the unmount, just before I did a kill -9
on mount.s3ql
The attached files indicate both, and moreover, the number of active
threads during the "kill -s USR1" command was much lower than during the
"setfattr" command. How much time did pass between these commands
(assuming that you issued both)?
I don't recall.
At least at the time that you issued the "kill" command, mount.s3ql was
busy doing the SSL handshake with the remote server, so while it looked
like it was hanging, it was probably waiting for the remote server.
It had been waiting a very long time, though I don't remember exactly,
for this case. I have limited the cache to 1GB so I don't have to wait
too long if I need to kill a backup, pack up the computer and leave.
Because of this, I know from past experience the maximum amount of time
it takes to flush the cache and unmount using this network. I figure it
is dead if the network has remained up, but network and cpu load for this
process are minimal to zero and it has taken more than twice as long as it
should for the unmount. In this case it should be done in 15 to 20
minutes max, so figure it had been at least twice that. Sorry I don't
have a better answer. If you have a suggestion for a better way to tell
if the filesystem is hung, it would be helpful. On one occasion I let a
hung system sit for hours to see if it would recover (it didn't).
Regards,
Shannon C. Dealy | DeaTech Research Inc.
de...@deatech.com | - Custom Software Development -
USA Phone: +1 800-467-5820 | - Natural Building Instruction -
numbers : +1 541-929-4089 | www.deatech.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
