A different lockdep chain, from test btrfs/014:
[ 229.850151] ==
[ 229.850788] [ INFO: possible circular locking dependency detected ]
[ 229.850788] 3.15.0-rc7-default+ #146 Tainted: GW
[ 229.850788] --
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/27/14, 7:26 AM, David Sterba wrote:
> A different lockdep chain, from test btrfs/014:
Are you sure this one was with the new patch? We shouldn't be holding
groups_sem anymore in btrfs_remove_block_group while performing the
kobject ops.
- -Jeff
On Tue, May 27, 2014 at 08:14:11AM -0400, Jeff Mahoney wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 5/27/14, 7:26 AM, David Sterba wrote:
> > A different lockdep chain, from test btrfs/014:
>
> Are you sure this one was with the new patch? We shouldn't be holding
> groups_sem a
On Sun, May 25, 2014 at 03:55:44AM +0100, Filipe David Borba Manana wrote:
> We were setting the BTRFS_ROOT_SUBVOL_DEAD flag on the root of the
> parent of our target snapshot, instead of setting it in the target
> snapshot's root.
>
> This is easy to observe by running the following scenario:
>
On 05/26/2014 09:35 PM, Jeff Mahoney wrote:
> We are currently allocating space_info objects in an array when we
> allocate space_info. When a user does something like:
>
> # btrfs balance start -mconvert=raid1 -dconvert=raid1 /mnt
> # btrfs balance start -mconvert=single -dconvert=single /mnt -f
On Fri, May 23, 2014 at 11:36:52AM +0800, Wang Shilong wrote:
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -513,6 +513,14 @@ int btrfs_parse_options(struct btrfs_root *root, char
> *options)
> btrfs_info(root->fs_info,
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/27/14, 12:10 PM, Chris Mason wrote:
> On 05/26/2014 09:35 PM, Jeff Mahoney wrote:
>> We are currently allocating space_info objects in an array when
>> we allocate space_info. When a user does something like:
>>
>> # btrfs balance start -mconvert
We are currently allocating space_info objects in an array when we
allocate space_info. When a user does something like:
# btrfs balance start -mconvert=raid1 -dconvert=raid1 /mnt
# btrfs balance start -mconvert=single -dconvert=single /mnt -f
# btrfs balance start -mconvert=raid1 -dconvert=raid1
On 05/27/2014 12:59 PM, Jeff Mahoney wrote:
> We are currently allocating space_info objects in an array when we
> allocate space_info. When a user does something like:
>
> # btrfs balance start -mconvert=raid1 -dconvert=raid1 /mnt
> # btrfs balance start -mconvert=single -dconvert=single /mnt -f
On 05/27/2014 01:08 PM, Chris Mason wrote:
> On 05/27/2014 12:59 PM, Jeff Mahoney wrote:
>> We are currently allocating space_info objects in an array when we
>> allocate space_info. When a user does something like:
>>
>> # btrfs balance start -mconvert=raid1 -dconvert=raid1 /mnt
>> # btrfs balan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/27/14, 1:22 PM, Chris Mason wrote:
>
>
> On 05/27/2014 01:08 PM, Chris Mason wrote:
>> On 05/27/2014 12:59 PM, Jeff Mahoney wrote:
>>> We are currently allocating space_info objects in an array when
>>> we allocate space_info. When a user does s
On 05/27/2014 01:20 PM, Jeff Mahoney wrote:
> - gpg control packet
> On 5/27/14, 1:22 PM, Chris Mason wrote:
>
>
>> On 05/27/2014 01:08 PM, Chris Mason wrote:
>>> On 05/27/2014 12:59 PM, Jeff Mahoney wrote:
We are currently allocating space_info objects in an array when
we allocate sp
On heavy workloads, we're seeing soft lockup warnings on
root->inode_lock in __btrfs_release_delayed_node. The low hanging fruit
is to reduce the size of the critical section.
Signed-off-by: Jeff Mahoney
---
fs/btrfs/delayed-inode.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
d
Hi,
Btrfs-transaction keeps blocking for me on all 3.15-rc versions.
3.14 does not have this issue.
The process never gets unstuck. btrfs fi sync does not help. A hard
reboot seems to be the only way to recover.
The volume is still readable when it's in this state.
dmesg + sysrq-w is availabl
On 05/27/2014 02:11 PM, Torbjørn wrote:
> Hi,
>
> Btrfs-transaction keeps blocking for me on all 3.15-rc versions.
> 3.14 does not have this issue.
> The process never gets unstuck. btrfs fi sync does not help. A hard
> reboot seems to be the only way to recover.
>
> The volume is still readabl
On 05/23/2014 07:13 PM, Marc MERLIN wrote:
> On Fri, May 23, 2014 at 04:24:49PM -0400, Chris Mason wrote:
>>> I was able to kill btrfs send and receive, but mencoder is very hung, and
>>> sync does not finish either:
>>> 10654 merlin syncsync_inodes_sb
>>> 17191 merlin
On 05/27/2014 10:08 PM, Torbjørn wrote:
On 05/27/2014 09:09 PM, Chris Mason wrote:
On 05/27/2014 02:11 PM, Torbjørn wrote:
Hi,
Btrfs-transaction keeps blocking for me on all 3.15-rc versions.
3.14 does not have this issue.
The process never gets unstuck. btrfs fi sync does not help. A hard
re
On 05/27/2014 04:42 PM, Torbjørn wrote:
> On 05/27/2014 10:08 PM, Torbjørn wrote:
>> On 05/27/2014 09:09 PM, Chris Mason wrote:
>>>
>>> On 05/27/2014 02:11 PM, Torbjørn wrote:
Hi,
Btrfs-transaction keeps blocking for me on all 3.15-rc versions.
3.14 does not have this issue.
>>>
On 05/27/2014 04:50 PM, Chris Mason wrote:
> On 05/27/2014 04:42 PM, Torbjørn wrote:
>> On 05/27/2014 10:08 PM, Torbjørn wrote:
>>> On 05/27/2014 09:09 PM, Chris Mason wrote:
On 05/27/2014 02:11 PM, Torbjørn wrote:
> Hi,
>
> Btrfs-transaction keeps blocking for me on all 3.15-
Hi David,
On 05/28/2014 12:22 AM, David Sterba wrote:
On Fri, May 23, 2014 at 11:36:52AM +0800, Wang Shilong wrote:
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -513,6 +513,14 @@ int btrfs_parse_options(struct btrfs_root *root, char
*options)
btrfs_i
On 05/16/2014 11:40 PM, David Sterba wrote:
On Thu, May 08, 2014 at 09:26:49AM +0800, Wang Shilong wrote:
This patch adds an option '--check-data-csum' to verify data csums.
fsck won't check data csums unless users specify this option explictly.
Nice.
+static int read_extent_data(struct btrfs
On 27. mai 2014 23:15, Chris Mason wrote:
On 05/27/2014 04:50 PM, Chris Mason wrote:
On 05/27/2014 04:42 PM, Torbjørn wrote:
On 05/27/2014 10:08 PM, Torbjørn wrote:
On 05/27/2014 09:09 PM, Chris Mason wrote:
On 05/27/2014 02:11 PM, Torbjørn wrote:
Hi,
Btrfs-transaction keeps blocking for me
Hi,
I have a Btrfs RAID 10 (data and metadata) file system that I believe
suffered a disk failure. In my attempt to replace the disk, I think
that I've made the problem worse and need some help recovering it.
I happened to notice a lot of errors in the journal:
end_request: I/O error, dev dm-11,
23 matches
Mail list logo
