2011/2/24 Maria Wikström <ma...@ponstudios.se>: > mån 2011-02-21 klockan 09:51 +0800 skrev Zhong, Xin: >> The backtrace in your attachment looks like a known bug of 2.6.37 which have >> already been fixed in 2.6.38. I have no idea why latest btrfs still hang in >> your environment if there's no debug info... >> > > Haha, yes that's very hard :) > > 2.6.38-rc6 and btrfs-unstable behaves the same way. I can close the > process with ctrl+c and it disappear a few seconds later. There is no > CPU usage. Reading works because I can start htop and watch "svn info" > disappear, but everything writing to btrfs slows down to a crawl. It > takes about 1 minute to log in. So I had to put the logs on an other > partition using ext3 to get the output from sysrq+t. >
I believe I've been experiencing this issue also. However, my problem usually results in a "No space left on device" error rather than a lock-up or crash. But I've bisected my issue to this patch, and my "btrfs fi show" and "btrfs fi df" looks similar to others who've posted to this tread with all my space being allocated, but not used. I've been playing around with ftrace to try to get some information on the issue. Since I'm getting a soft error, I can used a command like "echo 1 > tracing_on; emerge -1av openmotif; echo 0 > tracing_on" to end the trace as soon as the build fails. The traces are probably too large for the M/L (~275kb compressed), so I've put them up on my local server in case anybody can find them useful: http://dontpanic.dyndns.org/emerge-openmotif-ftrace.gz I'm still only capturing the tail end of the problem, but maybe someone will find these insightful. Let me know if you want me to increase the ftrace buffer size or insert some trace_printk debugging statements. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
