We might have had an item with the previous key in the tree right
before we released our path. And after we released our path, that
item might have been pushed to the first slot (0) of the leaf we
were holding due to a tree balance. Alternatively, an item with the
previous key can exist as the only
On 6/7/14, 8:41 AM, Christoph Hellwig wrote:
> On Fri, Jun 06, 2014 at 10:52:48AM -0500, Eric Sandeen wrote:
>> On 6/6/14, 5:03 AM, Karel Zak wrote:
>>> On Fri, Jun 06, 2014 at 11:44:28AM +0200, Karel Zak wrote:
I personally have no problem to maintain information about arbitrary
FS in
On Sat, Jun 07, 2014 at 06:41:50AM -0700, Christoph Hellwig wrote:
> On Fri, Jun 06, 2014 at 10:52:48AM -0500, Eric Sandeen wrote:
> > On 6/6/14, 5:03 AM, Karel Zak wrote:
> > > On Fri, Jun 06, 2014 at 11:44:28AM +0200, Karel Zak wrote:
> > >> I personally have no problem to maintain information a
Hello Chris Mason,
The patch 263524b4ac6b: "Btrfs: split up __extent_writepage to lower
stack usage" from May 21, 2014, leads to the following static checker
warning:
fs/btrfs/extent_io.c:4071 try_release_extent_state()
warn: use 'mask' here instead of GFP_XXX?
fs/btrfs/extent_io
On 06/09/2014 10:40 AM, Dan Carpenter wrote:
> Hello Chris Mason,
>
> The patch 263524b4ac6b: "Btrfs: split up __extent_writepage to lower
> stack usage" from May 21, 2014, leads to the following static checker
> warning:
>
> fs/btrfs/extent_io.c:4071 try_release_extent_state()
> warn
Hi all,
It seems that some recent changes to btrfs tests make it hang during boot:
[ 49.730033] NMI watchdog: BUG: soft lockup - CPU#34 stuck for 23s!
[swapper/0:1]
[ 49.730033] Modules linked in:
[ 49.730033] hardirqs last enabled at (6389143): restore_args
(arch/x86/kernel/entry_64.S:82
On 06/09/2014 11:16 AM, Sasha Levin wrote:
> Hi all,
>
> It seems that some recent changes to btrfs tests make it hang during boot:
>
> [ 49.730033] NMI watchdog: BUG: soft lockup - CPU#34 stuck for 23s!
> [swapper/0:1]
> [ 49.730033] Modules linked in:
> [ 49.730033] hardirqs last enabled
On 06/09/2014 11:59 AM, Chris Mason wrote:
> On 06/09/2014 11:16 AM, Sasha Levin wrote:
>> > Hi all,
>> >
>> > It seems that some recent changes to btrfs tests make it hang during boot:
>> >
>> > [ 49.730033] NMI watchdog: BUG: soft lockup - CPU#34 stuck for 23s!
>> > [swapper/0:1]
>> > [ 49
I did a balance on a system that had 3.11 (yes, I know, it's old). It hung.
So, I rebooted with 3.13, and it failed in fs/btrfs/relocation
Problem #1: I cannot stop the relocation. It starts on its own as soon as I
mount the FS, and I can't stop it.
Is there a bug to fix that?
Problem #2: I reboo
On Mon, 9 Jun 2014 16:40:07 Marc MERLIN wrote:
> I did a balance on a system that had 3.11 (yes, I know, it's old). It hung.
> So, I rebooted with 3.13, and it failed in fs/btrfs/relocation
>
> Problem #1: I cannot stop the relocation. It starts on its own as soon as I
> mount the FS, and I can't
Original Message
Subject: [PATCH V3] Btrfs: device_list_add() should not update list when
mounted
From: Anand Jain
To: linux-btrfs@vger.kernel.org
Date: 2014年06月06日 11:26
(looks like there was some sendmail problem I don't see this in the btrfs list,
sending again. sorry for
On Fri, May 30, 2014 at 04:52:51PM +0800, Xing Gu wrote:
> Regression test for resizing 'thread_pool' when remount the fs.
Ping for btrfs test reviewers - is this test useful at all?
> Signed-off-by: Xing Gu
> ---
> tests/btrfs/055 | 55
> +++
On Tue, Jun 03, 2014 at 03:37:41PM +0100, Filipe David Borba Manana wrote:
> Regression test for the btrfs ioctl clone operation when the source range
> contains hole(s) and the FS has the NO_HOLES feature enabled (file holes
> don't need file extent items in the btree to represent them).
>
> This
On 10/06/14 09:25, Qu Wenruo wrote:
Original Message
Subject: [PATCH V3] Btrfs: device_list_add() should not update list when
mounted
From: Anand Jain
To: linux-btrfs@vger.kernel.org
Date: 2014年06月06日 11:26
(looks like there was some sendmail problem I don't see this in the
Original Message
Subject: Re: [PATCH V3] Btrfs: device_list_add() should not update list
when mounted
From: Anand Jain
To: Qu Wenruo , linux-btrfs@vger.kernel.org
Date: 2014年06月10日 09:48
On 10/06/14 09:25, Qu Wenruo wrote:
Original Message
Subject: [PAT
On Mon, Jun 09, 2014 at 03:48:52AM +0100, Filipe David Borba Manana wrote:
> Regression test for btrfs ioctl clone operation + fsync + log
> recovery. The issue was that doing an fsync after cloning into
> a file didn't gave any persistence guarantees as it should.
> What happened was that the in m
On Tue, Jun 10, 2014 at 10:32:33AM +1000, Russell Coker wrote:
> On Mon, 9 Jun 2014 16:40:07 Marc MERLIN wrote:
> > I did a balance on a system that had 3.11 (yes, I know, it's old). It hung.
> > So, I rebooted with 3.13, and it failed in fs/btrfs/relocation
> >
> > Problem #1: I cannot stop the r
17 matches
Mail list logo
