Excerpts from Mitch Harder's message of 2011-02-24 11:03:07 -0500: > On Thu, Feb 24, 2011 at 10:00 AM, Chris Mason <chris.mason@xxxxxxxxxx> wrote: > > Excerpts from Mitch Harder's message of 2011-02-24 10:55:15 -0500: > >> 2011/2/24 Maria WikstrÃm <maria@xxxxxxxxxxxxx>: > >> > 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. > >> > > > > Sorry, which patch did you bisect the problem down to? > > > > The patch at the head of this thread: > > Btrfs: pwrite blocked when writing from the mmaped buffer of the same page Hmmm, that patch shouldn't be changing our performance under delalloc pressure, and it really shouldn't impact early enospc. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
