On Wed, Jan 22, 2014 at 12:07 PM, Tomasz Chmielewski wrote:
> I could still see the bug (below) with 3.13 and tried to apply the patch.
>
> It did apply:
>
> patching file fs/btrfs/ctree.c
> Hunk #1 succeeded at 39 with fuzz 2.
> Hunk #2 succeeded at 475 (offset 1 line).
> Hunk #3 succeeded at 485
I could still see the bug (below) with 3.13 and tried to apply the patch.
It did apply:
patching file fs/btrfs/ctree.c
Hunk #1 succeeded at 39 with fuzz 2.
Hunk #2 succeeded at 475 (offset 1 line).
Hunk #3 succeeded at 485 (offset 1 line).
Hunk #4 succeeded at 505 (offset 1 line).
Hunk #5 succeed
I've applied it to 3.13-rc8, let's see if it helps.
--
Tomasz Chmielewski
On Mon, 13 Jan 2014 15:06:06 +0800
Wang Shilong wrote:
> On 01/13/2014 06:47 AM, Tomasz Chmielewski wrote:
>
> Hello Tomasz,
>
> Chris recently sent a patch that addressed a race condition with
> loading inode, i thin
Hard to tell, as I only saw it once.
It happened during rsync; there were snapshots created and dropped a few
minutes before.
On Mon, 13 Jan 2014 09:24:13 +0800
Gui Hecheng wrote:
> Hi Tomasz,
> Similar bug has been reported by Pedro Fonseca
> before, how do you trigger this or what operation
On 01/13/2014 06:47 AM, Tomasz Chmielewski wrote:
Hello Tomasz,
Chris recently sent a patch that addressed a race condition with
loading inode, i think it might be related to your first dmesg warning.
Chris' patch url can be seen:
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg3033
Hi Tomasz,
Similar bug has been reported by Pedro Fonseca
before, how do you trigger this or what operations are you doing?
Thanks,
Gui
On Sun, 2014-01-12 at 23:47 +0100, Tomasz Chmielewski wrote:
> Just had this on a btrfs filesystem running 3.13-rc7.
>
> The filesystem was working fine till n
