On Thu, Feb 24, 2011 at 10:19 AM, Chris Mason <chris.mason@xxxxxxxxxx> wrote: > 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. > I've bisected this issue around where this patch went into git, and I've also constructed a testing patch that reverts this patch, and placed it on top of the current Btrfs git sources (I understand this patch addresses a real issue, this was just for testing). It could be that this patch just "uncovers" another problem, but all my tests seem to point to this patch triggering this issue. -- 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
