Re: [PATCH v2]Btrfs: pwrite blocked when writing from the mmaped buffer of the same page

[Mitch Harder <mitch.harder@sabayonlinux.org>]

On Thu, Feb 24, 2011 at 10:19 AM, Chris Mason <chris.mason@oracle.com> =
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@oracle.co=
m> wrote:
>> > Excerpts from Mitch Harder's message of 2011-02-24 10:55:15 -0500:
>> >> 2011/2/24 Maria Wikstr=F6m <maria@ponstudios.se>:
>> >> > m=E5n 2011-02-21 klockan 09:51 +0800 skrev Zhong, Xin:
>> >> >> The backtrace in your attachment looks like a known bug of 2.6=
=2E37 which have already been fixed in 2.6.38. I have no idea why lates=
t 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 "sv=
n info"
>> >> > disappear, but everything writing to btrfs slows down to a craw=
l. 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. =A0However, my =
problem
>> >> usually results in a "No space left on device" error rather than =
a
>> >> lock-up or crash. =A0But I've bisected my issue to this patch, an=
d 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 u=
sed.
>> >>
>> >
>> > 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 sam=
e 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html