Re: kernel BUG at fs/btrfs/volumes.c:2733

2012-04-10 Thread Ilya Dryomov 
On Fri, Mar 30, 2012 at 10:44:05PM +0200, Sander wrote:
> Ilya Dryomov wrote (ao):
> > On Fri, Mar 30, 2012 at 07:49:56PM +0200, Sander wrote:
> > Thanks. btrfs-debug-tree confirms that you've got a balance item on
> > media.
> 
> > > > > > After that mount it back and see if there is "btrfs: continuing
> > > > > > balance" line in dmesg (and if btrfs-balance kthread shows up)?
> > > 
> > > There is no such line in dmesg, and currently no btrfs-balance kthread
> > > is running. I've pulled Chris Masons for-linus and booted with the
> > > resulting kernel.
> > 
> > And given the above it's weird. We are failing to locate the item
> > during mount for some reason and I would like to find out why. So if
> > you are up for running debugging patches (really just compiling btrfs
> > module and sending me dmesg output) I would appreciate that.
> 
> Sure, please send me patches.

I'm sorry this took a week, I was backed up.  If you still have that fs
around in that state, could you please apply the patch below, mount it
and send me dmesg output ?  (no need to run balance or anything, just
mount)

Thanks,

Ilya



diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 20196f4..86fa082 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1867,6 +1867,7 @@ int open_ctree(struct super_block *sb,
csum_root = fs_info->csum_root = btrfs_alloc_root(fs_info);
chunk_root = fs_info->chunk_root = btrfs_alloc_root(fs_info);
dev_root = fs_info->dev_root = btrfs_alloc_root(fs_info);
+printk("open_ctree\n");
 
if (!tree_root || !extent_root || !csum_root ||
!chunk_root || !dev_root) {
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index a872b48..2e39348 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -2834,6 +2834,7 @@ static int balance_kthread(void *data)
mutex_lock(&fs_info->balance_mutex);
 
set_balance_control(bctl);
+printk("balance_kthread: flags %llu\n", (unsigned long long)bctl->flags);
 
if (btrfs_test_opt(fs_info->tree_root, SKIP_BALANCE)) {
printk(KERN_INFO "btrfs: force skipping balance\n");
@@ -2858,6 +2859,7 @@ int btrfs_recover_balance(struct btrfs_root *tree_root)
struct btrfs_key key;
int ret;
 
+printk("recover_balance\n");
path = btrfs_alloc_path();
if (!path)
return -ENOMEM;
@@ -2872,7 +2874,11 @@ int btrfs_recover_balance(struct btrfs_root *tree_root)
key.type = BTRFS_BALANCE_ITEM_KEY;
key.offset = 0;
 
+printk("key.obj %llu\n", (unsigned long long)key.objectid);
+printk("key.type %d\n", key.type);
+printk("key.off %llu\n", (unsigned long long)key.offset);
ret = btrfs_search_slot(NULL, tree_root, &key, path, 0, 0);
+printk("search ret %d\n", ret);
if (ret < 0)
goto out_bctl;
if (ret > 0) { /* ret = -ENOENT; */
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG at fs/btrfs/volumes.c:2733

2012-03-30 Thread Sander 
Ilya Dryomov wrote (ao):
> On Fri, Mar 30, 2012 at 07:49:56PM +0200, Sander wrote:
> Thanks. btrfs-debug-tree confirms that you've got a balance item on
> media.

> > > > > After that mount it back and see if there is "btrfs: continuing
> > > > > balance" line in dmesg (and if btrfs-balance kthread shows up)?
> > 
> > There is no such line in dmesg, and currently no btrfs-balance kthread
> > is running. I've pulled Chris Masons for-linus and booted with the
> > resulting kernel.
> 
> And given the above it's weird. We are failing to locate the item
> during mount for some reason and I would like to find out why. So if
> you are up for running debugging patches (really just compiling btrfs
> module and sending me dmesg output) I would appreciate that.

Sure, please send me patches.

In the mean time, I got these (not related I guess, but it's the first
time it mentions btrfs, and I wonder where gzip is from):

[10013.866973] kworker/0:2: page allocation failure: order:3, mode:0x20
[10013.866973] [] (unwind_backtrace+0x1/0x8a) from [] 
(warn_alloc_failed+0x9f/0xc4)
[10013.881286] [] (warn_alloc_failed+0x9f/0xc4) from [] 
(__alloc_pages_nodemask+0x3e3/0x410)
[10013.883270] [] (__alloc_pages_nodemask+0x3e3/0x410) from 
[] (cache_alloc_refill+0x1ab/0x364)
[10013.893646] [] (cache_alloc_refill+0x1ab/0x364) from [] 
(__kmalloc+0x59/0x84)
[10013.893646] [] (__kmalloc+0x59/0x84) from [] 
(__alloc_skb+0x37/0xb2)
[10013.922058] [] (__alloc_skb+0x37/0xb2) from [] 
(__netdev_alloc_skb+0x15/0x2e)
[10013.922058] [] (__netdev_alloc_skb+0x15/0x2e) from [] 
(rx_submit+0x15/0x130)
[10013.931365] [] (rx_submit+0x15/0x130) from [] 
(usb_hcd_giveback_urb+0x3f/0x74)
[10013.931365] [] (usb_hcd_giveback_urb+0x3f/0x74) from [] 
(ehci_urb_done+0x5f/0x68)
[10013.931365] [] (ehci_urb_done+0x5f/0x68) from [] 
(qh_completions+0x6f/0x2b8)
[10013.968780] [] (qh_completions+0x6f/0x2b8) from [] 
(ehci_work+0x65/0x5d8)
[10013.968780] [] (ehci_work+0x65/0x5d8) from [] 
(ehci_irq+0x171/0x198)
[10013.986175] [] (ehci_irq+0x171/0x198) from [] 
(usb_hcd_irq+0x1f/0x3a)
[10013.986175] [] (usb_hcd_irq+0x1f/0x3a) from [] 
(handle_irq_event_percpu+0x19/0xd4)
[10013.986175] [] (handle_irq_event_percpu+0x19/0xd4) from 
[] (handle_irq_event+0x29/0x3c)
[10013.986175] [] (handle_irq_event+0x29/0x3c) from [] 
(handle_fasteoi_irq+0x81/0xb4)
[10013.986175] [] (handle_fasteoi_irq+0x81/0xb4) from [] 
(generic_handle_irq+0x13/0x1c)
[10014.02] [] (generic_handle_irq+0x13/0x1c) from [] 
(handle_IRQ+0x4b/0x7c)
[10014.02] [] (handle_IRQ+0x4b/0x7c) from [] 
(gic_handle_irq+0x4d/0x68)
[10014.052398] [] (gic_handle_irq+0x4d/0x68) from [] 
(__irq_svc+0x3b/0x60)
[10014.052398] Exception stack(0xedf73f00 to 0xedf73f48)
[10014.052398] 3f00: ef002a64 ef00a440  ee097b40 ef000140 ef002a40 
 c1a40d08
[10014.052398] 3f20:  c1a40d08 c1a404bc  0020 edf73f48 
c0421079 c042107a
[10014.052398] 3f40: 6033 
[10014.083526] [] (__irq_svc+0x3b/0x60) from [] 
(_raw_spin_unlock_irq+0x8/0xa)
[10014.083526] [] (_raw_spin_unlock_irq+0x8/0xa) from [] 
(cache_reap+0x5b/0xb8)
[10014.083526] [] (cache_reap+0x5b/0xb8) from [] 
(process_one_work+0x155/0x22e)
[10014.083526] [] (process_one_work+0x155/0x22e) from [] 
(worker_thread+0x127/0x1e8)
[10014.083526] [] (worker_thread+0x127/0x1e8) from [] 
(kthread+0x4d/0x60)
[10014.133026] [] (kthread+0x4d/0x60) from [] 
(kernel_thread_exit+0x1/0x6)
[10014.133026] Mem-info:
[10014.133026] Normal per-cpu:
[10014.133026] CPU0: hi:  186, btch:  31 usd: 156
[10014.133026] CPU1: hi:  186, btch:  31 usd: 168
[10014.152069] active_anon:19949 inactive_anon:506 isolated_anon:0
[10014.152069]  active_file:52991 inactive_file:52991 isolated_file:0
[10014.157104]  unevictable:469 dirty:2108 writeback:0 unstable:0
[10014.157104]  free:3283 slab_reclaimable:51064 slab_unreclaimable:5690
[10014.157104]  mapped:2477 shmem:522 pagetables:569 bounce:0
[10014.188293] Normal free:13132kB min:3512kB low:4388kB high:5268kB 
active_anon:79796kB inactive_anon:2024kB active_file:211964kB 
inactive_file:211964kB unevictable:1876kB isolated(anon):0kB isolated(file):0kB 
present:771136kB mlocked:0kB dirty:8432kB writeback:0kB mapped:9908kB 
shmem:2088kB slab_reclaimable:204256kB slab_unreclaimable:22760kB 
kernel_stack:1608kB pagetables:2276kB unstable:0kB bounce:0kB writeback_tmp:0kB 
pages_scanned:0 all_unreclaimable? no
[10014.188293] lowmem_reserve[]: 0 0
[10014.188293] Normal: 2383*4kB 278*8kB 34*16kB 26*32kB 0*64kB 0*128kB 0*256kB 
0*512kB 0*1024kB 0*2048kB 0*4096kB = 13132kB
[10014.188293] 107008 total pagecache pages
[10014.188293] 0 pages in swap cache
[10014.188293] Swap cache stats: add 0, delete 0, find 0/0
[10014.253112] Free swap  = 0kB
[10014.261566] Total swap = 0kB
[10014.261566] 194560 pages of RAM
[10014.311492] 5438 free pages
[10014.314422] 3772 reserved pages
[10014.314422] 56747 slab pages
[10014.320709] 125870 pages shared
[10014.320709] 0 pages swap cached
[10015.815917] gzip: page allocation fail

Re: kernel BUG at fs/btrfs/volumes.c:2733

2012-03-30 Thread Ilya Dryomov 
On Fri, Mar 30, 2012 at 07:49:56PM +0200, Sander wrote:
> Hello Ilya,
> 
> Ilya Dryomov wrote (ao):
> > > > I'm definitely intrested in reproducing it. Could you please umount this
> > > > filesystem, capture the output of 'btrfs-debug-tree -d ' and post 
> > > > it
> > > > somewhere ?
> > > 
> > > Will do. It is the / filesystem, so I'll need to reboot.
> > 
> > I need this to confirm that balance item is on disk.
> 
> I'm sorry it took so long. I'll mail the output to you directly.

Thanks.  btrfs-debug-tree confirms that you've got a balance item on
media.

> 
> > > > After that mount it back and see if there is "btrfs: continuing
> > > > balance" line in dmesg (and if btrfs-balance kthread shows up)?
> 
> There is no such line in dmesg, and currently no btrfs-balance kthread
> is running. I've pulled Chris Masons for-linus and booted with the
> resulting kernel.

And given the above it's weird.  We are failing to locate the item
during mount for some reason and I would like to find out why.  So if
you are up for running debugging patches (really just compiling btrfs
module and sending me dmesg output) I would appreciate that.

If you don't want to do that you can try to compile btrfs-progs from
git, mount fs and run 'btrfs balance resume '.  If that doesn't
work I'll send you a small util that will simply delete the item from
disk.

Thanks,

Ilya
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG at fs/btrfs/volumes.c:2733

2012-03-30 Thread Sander 
Hello Ilya,

Ilya Dryomov wrote (ao):
> > > I'm definitely intrested in reproducing it. Could you please umount this
> > > filesystem, capture the output of 'btrfs-debug-tree -d ' and post it
> > > somewhere ?
> > 
> > Will do. It is the / filesystem, so I'll need to reboot.
> 
> I need this to confirm that balance item is on disk.

I'm sorry it took so long. I'll mail the output to you directly.

> > > After that mount it back and see if there is "btrfs: continuing
> > > balance" line in dmesg (and if btrfs-balance kthread shows up)?

There is no such line in dmesg, and currently no btrfs-balance kthread
is running. I've pulled Chris Masons for-linus and booted with the
resulting kernel.

> > > If so, just let it run, it should finish the balance and remove
> > > on-disk item. (You can query the status of running balance with 'btrfs
> > > balance status ')
> > 
> > Do I need newer tools for that? This is Debian Sid (unstable):
> 
> Yeah, you do. That command is in master now, but it's not really
> needed. If btrfs-balance shows up, just wait for it to finish, it
> should get rid of the balance item. If it doesn't show up but the item
> is there we will have to dig deeper.

Ok :-)

Sander

-- 
Humilis IT Services and Solutions
http://www.humilis.net
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG at fs/btrfs/volumes.c:2733

2012-03-29 Thread Ilya Dryomov 
On Thu, Mar 29, 2012 at 04:39:29PM +0200, Sander wrote:
> Hello Josef,
> 
> Josef Bacik wrote (ao):
> > On Thu, Mar 29, 2012 at 12:52:35PM +0200, Sander wrote:
> > > I can't seem to balance my btrfs filesystem. It segfaults, and gives a
> > > kernel bug:
> > > 
> > > [ 1355.139099] [ cut here ]
> > > [ 1355.139099] kernel BUG at fs/btrfs/volumes.c:2733!
> > > [ 1355.149322] Internal error: Oops - BUG: 0 [#1] SMP
> > > [ 1355.149322] Modules linked in:
> > > [ 1355.154479] CPU: 0Not tainted  (3.3.0 #8)
> > > [ 1355.162109] PC is at btrfs_balance+0x312/0xb04
> > > [ 1355.166778] LR is at btrfs_run_delayed_iputs+0x2d/0xac
> 
> > > The system is a pandaboard running a plain Linus kernel 3.3.0 with a
> > > btrfs filesystem, over two Intel 320 600GB ssd's, connected via usb (on
> > > an usb hub), on top of md_crypt. Mount options:
> > > "subvol=rootvolume,space_cache,inode_cache,compress=lzo,ssd"
> > > 
> > > Before the balance, I deleted about 2500 snapshots and waited for the
> > > btrfs kernel threads to calm down. Then I initiated a btrfs filesystem
> > > scrub. Unfortunately during the scrub, the filesystem balance started.
> > > Might be related.
> > 
> > Well that's kind of cool.  So 2 options
> > 
> > 1) If you are in a hurry and need this stuff back right away run btrfs fi
> > balance resume / and it should work, buuutt
> > 
> > 2) If you aren't in a hurry I'd really like to try and reproduce this 
> > locally
> > and if I can't I'd like to be able to send you patches to help me figure 
> > out how
> > to fix this problem.
> 
> I am in no hurry at all. The filesystem seems just fine the way it is
> (after a reboot), so there is no "stuff to get back right away". Does
> the kernel bug suggest the filesystem is fubar?

No, as I said in another mail you are trapping over a simle sanity
check.  FS should be OK.

Thanks,

Ilya
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG at fs/btrfs/volumes.c:2733

2012-03-29 Thread Ilya Dryomov 
On Thu, Mar 29, 2012 at 05:14:22PM +0200, Sander wrote:
> Ilya Dryomov wrote (ao):
> > On Thu, Mar 29, 2012 at 12:52:35PM +0200, Sander wrote:
> > > After a reboot, I tried again, with the same result:
> > > 
> > > [   81.048767] [ cut here ]
> > > [   81.053619] kernel BUG at fs/btrfs/volumes.c:2733!
> > > [   81.053619] Internal error: Oops - BUG: 0 [#1] SMP
> > > [   81.059295] Modules linked in:
> > > [   81.059295] CPU: 1Not tainted  (3.3.0 #8)
> > > [   81.071411] PC is at btrfs_balance+0x312/0xb04
> > > [   81.074890] LR is at btrfs_run_delayed_iputs+0x2d/0xac
> 
> > So you have balance item on disk, but the kernel doesn't seem to know
> > about it in advance, which is odd and so when you try to run balance it
> > panics on one of the safety checks.
> > 
> > > The system is a pandaboard running a plain Linus kernel 3.3.0 with a
> > > btrfs filesystem, over two Intel 320 600GB ssd's, connected via usb (on
> > > an usb hub), on top of md_crypt. Mount options:
> > > "subvol=rootvolume,space_cache,inode_cache,compress=lzo,ssd"
> > > 
> > > Before the balance, I deleted about 2500 snapshots and waited for the
> > > btrfs kernel threads to calm down. Then I initiated a btrfs filesystem
> > > scrub. Unfortunately during the scrub, the filesystem balance started.
> > > Might be related.
> > 
> > That's indeed pretty cool, I wonder how that could happen.
> 
> I create 5 snapshots of 5 different subvolumes every 5 minutes, and the
> system is low on memory:
> 
>  total   used   free sharedbuffers cached
> Mem:   745712 33  0  0480
> -/+ buffers/cache:231514
> Swap:0  0  0
> 
> There is ample space on the fileystem:
> panda:~# df -h /
> Filesystem  Size  Used Avail Use% 
> Mounted on
> /dev/mapper/ata-INTEL_SSDSA2CW600G3_CVPR112405AJ600FGN  1.1T   17G  1.1T   2% 
> /
> 
> panda:~# btrfs filesystem df /
> Data, RAID0: total=24.00GB, used=15.69GB
> System, RAID1: total=64.00MB, used=12.00KB
> System: total=4.00MB, used=0.00
> Metadata, RAID1: total=23.00GB, used=231.26MB
> 
> Do you need more information?

No, that's enough for now.

> 
> > I'm definitely intrested in reproducing it. Could you please umount this
> > filesystem, capture the output of 'btrfs-debug-tree -d ' and post it
> > somewhere ?
> 
> Will do. It is the / filesystem, so I'll need to reboot.

I need this to confirm that balance item is on disk.

> 
> > After that mount it back and see if there is "btrfs: continuing
> > balance" line in dmesg (and if btrfs-balance kthread shows up)?
> 
> There was none after the first reboot, but I'll pay extra attention to
> that after the next reboot.
> 
> > If so, just let it run, it should finish the balance and remove
> > on-disk item. (You can query the status of running balance with 'btrfs
> > balance status ')
> 
> Do I need newer tools for that? This is Debian Sid (unstable):

Yeah, you do.  That command is in master now, but it's not really
needed.  If btrfs-balance shows up, just wait for it to finish, it
should get rid of the balance item.  If it doesn't show up but the item
is there we will have to dig deeper.

Thanks,

Ilya
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG at fs/btrfs/volumes.c:2733

2012-03-29 Thread Sander 
Ilya Dryomov wrote (ao):
> On Thu, Mar 29, 2012 at 12:52:35PM +0200, Sander wrote:
> > After a reboot, I tried again, with the same result:
> > 
> > [   81.048767] [ cut here ]
> > [   81.053619] kernel BUG at fs/btrfs/volumes.c:2733!
> > [   81.053619] Internal error: Oops - BUG: 0 [#1] SMP
> > [   81.059295] Modules linked in:
> > [   81.059295] CPU: 1Not tainted  (3.3.0 #8)
> > [   81.071411] PC is at btrfs_balance+0x312/0xb04
> > [   81.074890] LR is at btrfs_run_delayed_iputs+0x2d/0xac

> So you have balance item on disk, but the kernel doesn't seem to know
> about it in advance, which is odd and so when you try to run balance it
> panics on one of the safety checks.
> 
> > The system is a pandaboard running a plain Linus kernel 3.3.0 with a
> > btrfs filesystem, over two Intel 320 600GB ssd's, connected via usb (on
> > an usb hub), on top of md_crypt. Mount options:
> > "subvol=rootvolume,space_cache,inode_cache,compress=lzo,ssd"
> > 
> > Before the balance, I deleted about 2500 snapshots and waited for the
> > btrfs kernel threads to calm down. Then I initiated a btrfs filesystem
> > scrub. Unfortunately during the scrub, the filesystem balance started.
> > Might be related.
> 
> That's indeed pretty cool, I wonder how that could happen.

I create 5 snapshots of 5 different subvolumes every 5 minutes, and the
system is low on memory:

 total   used   free sharedbuffers cached
Mem:   745712 33  0  0480
-/+ buffers/cache:231514
Swap:0  0  0

There is ample space on the fileystem:
panda:~# df -h /
Filesystem  Size  Used Avail Use% 
Mounted on
/dev/mapper/ata-INTEL_SSDSA2CW600G3_CVPR112405AJ600FGN  1.1T   17G  1.1T   2% /

panda:~# btrfs filesystem df /
Data, RAID0: total=24.00GB, used=15.69GB
System, RAID1: total=64.00MB, used=12.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=23.00GB, used=231.26MB

Do you need more information?

> I'm definitely intrested in reproducing it. Could you please umount this
> filesystem, capture the output of 'btrfs-debug-tree -d ' and post it
> somewhere ?

Will do. It is the / filesystem, so I'll need to reboot.

> After that mount it back and see if there is "btrfs: continuing
> balance" line in dmesg (and if btrfs-balance kthread shows up)?

There was none after the first reboot, but I'll pay extra attention to
that after the next reboot.

> If so, just let it run, it should finish the balance and remove
> on-disk item. (You can query the status of running balance with 'btrfs
> balance status ')

Do I need newer tools for that? This is Debian Sid (unstable):

Btrfs Btrfs v0.19

panda:~# btrfs filesystem balance status /
ERROR: 'filesystem balance' requires 1 arg(s)

panda:~# btrfs balance status /
ERROR: unknown command 'balance'
Usage:
..

-- 
Humilis IT Services and Solutions
http://www.humilis.net
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG at fs/btrfs/volumes.c:2733

2012-03-29 Thread Sander 
Hello Josef,

Josef Bacik wrote (ao):
> On Thu, Mar 29, 2012 at 12:52:35PM +0200, Sander wrote:
> > I can't seem to balance my btrfs filesystem. It segfaults, and gives a
> > kernel bug:
> > 
> > [ 1355.139099] [ cut here ]
> > [ 1355.139099] kernel BUG at fs/btrfs/volumes.c:2733!
> > [ 1355.149322] Internal error: Oops - BUG: 0 [#1] SMP
> > [ 1355.149322] Modules linked in:
> > [ 1355.154479] CPU: 0Not tainted  (3.3.0 #8)
> > [ 1355.162109] PC is at btrfs_balance+0x312/0xb04
> > [ 1355.166778] LR is at btrfs_run_delayed_iputs+0x2d/0xac

> > The system is a pandaboard running a plain Linus kernel 3.3.0 with a
> > btrfs filesystem, over two Intel 320 600GB ssd's, connected via usb (on
> > an usb hub), on top of md_crypt. Mount options:
> > "subvol=rootvolume,space_cache,inode_cache,compress=lzo,ssd"
> > 
> > Before the balance, I deleted about 2500 snapshots and waited for the
> > btrfs kernel threads to calm down. Then I initiated a btrfs filesystem
> > scrub. Unfortunately during the scrub, the filesystem balance started.
> > Might be related.
> 
> Well that's kind of cool.  So 2 options
> 
> 1) If you are in a hurry and need this stuff back right away run btrfs fi
> balance resume / and it should work, buuutt
> 
> 2) If you aren't in a hurry I'd really like to try and reproduce this locally
> and if I can't I'd like to be able to send you patches to help me figure out 
> how
> to fix this problem.

I am in no hurry at all. The filesystem seems just fine the way it is
(after a reboot), so there is no "stuff to get back right away". Does
the kernel bug suggest the filesystem is fubar?

I'll keep the filesystem as is (no resume) and am happy to test any
patches you have.

Sander

-- 
Humilis IT Services and Solutions
http://www.humilis.net
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG at fs/btrfs/volumes.c:2733

2012-03-29 Thread Ilya Dryomov 
On Thu, Mar 29, 2012 at 12:52:35PM +0200, Sander wrote:
> Hello all,
> 
> I can't seem to balance my btrfs filesystem. It segfaults, and gives a
> kernel bug:
> 
> [ 1355.139099] [ cut here ]
> [ 1355.139099] kernel BUG at fs/btrfs/volumes.c:2733!
> [ 1355.149322] Internal error: Oops - BUG: 0 [#1] SMP
> [ 1355.149322] Modules linked in:
> [ 1355.154479] CPU: 0Not tainted  (3.3.0 #8)
> [ 1355.162109] PC is at btrfs_balance+0x312/0xb04
> [ 1355.166778] LR is at btrfs_run_delayed_iputs+0x2d/0xac
> [ 1355.166931] pc : []lr : []psr: 6033
> [ 1355.166931] sp : cb141d98  ip :   fp : be83fdb4
> [ 1355.166931] r10:   r9 :   r8 : 
> [ 1355.184173] r7 :   r6 : ffef  r5 : ede7f000  r4 : ed730e00
> [ 1355.189636] r3 :   r2 :   r1 :   r0 : 0007
> [ 1355.203277] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment 
> user
> [ 1355.203277] Control: 50c5387d  Table: 8b15c04a  DAC: 0015
> [ 1355.203277] Process btrfs (pid: 1798, stack limit = 0xcb1402f8)
> [ 1355.203277] Stack: (0xcb141d98 to 0xcb142000)
> [ 1355.203277] 1d80:   
> c145f944 
> [ 1355.227691] 1da0:     0003 ee478d40 
> 0015 
> [ 1355.227691] 1dc0:       
>  
> [ 1355.253356] 1de0:       
> ede7fcd4 ede7fcd8
> [ 1355.253356] 1e00:      271aee1c 
> 000200da c0160fd5
> [ 1355.253356] 1e20: ed74ec00  d6257680  ed730e00  
> ede7f4e8 ede7fcb0
> [ 1355.279022] 1e40: ede7f000  be83fdb4 c013d489 eec9c118 be83ebf8 
> ed74ec00 eec8a370
> [ 1355.279022] 1e60: d6257680  eec8a528  be83fdb4 c013fc6b 
> 001d 00eb
> [ 1355.279022] 1e80: 0007 0001 e6f7e680 c015cecd cb141ea4  
> cb141ef0 
> [ 1355.296142] 1ea0: cb15c000 01ff   0001  
> eeabaac0 0001
> [ 1355.296142] 1ec0: ed5428c0 c1414788 d6257688 00eb cb141ef0 c016011b 
> cb141ef0 
> [ 1355.321807] 1ee0: 0001 c016018f  0817 0001 271aee1c 
> ede92250 d6257680
> [ 1355.321807] 1f00: be83ebf8 be83ebf8 eec8a528  cb14  
> be83fdb4 c0088075
> [ 1355.321807] 1f20: 4000 c00887ff     
>  
> [ 1355.338928] 1f40:      271aee1c 
> 0003 d6257680
> [ 1355.338928] 1f60: be83ebf8 5000940c d6257680 be83ebf8 5000940c 0003 
>  cb14
> [ 1355.364593] 1f80:  c008885d 0003  be83fec7 0003 
> 0013c478 0036
> [ 1355.364593] 1fa0: c000c5a4 c000c401 be83fec7 0003 0003 5000940c 
> be83ebf8 be83fbf8
> [ 1355.364593] 1fc0: be83fec7 0003 0013c478 0036 0002 b7ad 
> 0001 be83fdb4
> [ 1355.381713] 1fe0: 00024b3d be83ebf0 b7f7 b6ea7f9c 8010 0003 
> 00052d17 00090224
> [ 1355.381713] [] (btrfs_balance+0x312/0xb04) from [] 
> (btrfs_ioctl_balance+0x109/0x174)
> [ 1355.381713] [] (btrfs_ioctl_balance+0x109/0x174) from 
> [] (btrfs_ioctl+0xbf5/0xd42)
> [ 1355.418518] [] (btrfs_ioctl+0xbf5/0xd42) from [] 
> (vfs_ioctl+0xd/0x28)
> [ 1355.418518] [] (vfs_ioctl+0xd/0x28) from [] 
> (do_vfs_ioctl+0x35d/0x38e)
> [ 1355.427093] [] (do_vfs_ioctl+0x35d/0x38e) from [] 
> (sys_ioctl+0x2d/0x44)
> [ 1355.88] [] (sys_ioctl+0x2d/0x44) from [] 
> (ret_fast_syscall+0x1/0x44)
> [ 1355.88] Code: d107 f116 0f11 d100 (de02) 4620 
> [ 1355.458343] ---[ end trace f06b6b8fcd08e6d5 ]---
> 
> A new 'btrfs filesystem balance /' seems to just hang, and is
> unkillable.
> 
> After a reboot, I tried again, with the same result:
> 
> [   81.048767] [ cut here ]
> [   81.053619] kernel BUG at fs/btrfs/volumes.c:2733!
> [   81.053619] Internal error: Oops - BUG: 0 [#1] SMP
> [   81.059295] Modules linked in:
> [   81.059295] CPU: 1Not tainted  (3.3.0 #8)
> [   81.071411] PC is at btrfs_balance+0x312/0xb04
> [   81.074890] LR is at btrfs_run_delayed_iputs+0x2d/0xac
> [   81.074890] pc : []lr : []psr: 6133
> [   81.074890] sp : edda5d98  ip :   fp : beb62d64
> [   81.093475] r10:   r9 :   r8 : 
> [   81.098327] r7 :   r6 : ffef  r5 : ed73f000  r4 : ee311c00
> [   81.098327] r3 :   r2 :   r1 :   r0 : 0007
> [   81.112609] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment 
> user
> [   81.112609] Control: 50c5387d  Table: a7fb404a  DAC: 0015
> [   81.112609] Process btrfs (pid: 752, stack limit = 0xedda42f8)
> [   81.132354] Stack: (0xedda5d98 to 0xedda6000)
> [   81.132354] 5d80:   
> c145f944 
> [   81.145477] 5da0:     0003 eeabca40 
> 0015 000

Re: kernel BUG at fs/btrfs/volumes.c:2733

2012-03-29 Thread Josef Bacik 
On Thu, Mar 29, 2012 at 12:52:35PM +0200, Sander wrote:
> Hello all,
> 
> I can't seem to balance my btrfs filesystem. It segfaults, and gives a
> kernel bug:
> 
> [ 1355.139099] [ cut here ]
> [ 1355.139099] kernel BUG at fs/btrfs/volumes.c:2733!
> [ 1355.149322] Internal error: Oops - BUG: 0 [#1] SMP
> [ 1355.149322] Modules linked in:
> [ 1355.154479] CPU: 0Not tainted  (3.3.0 #8)
> [ 1355.162109] PC is at btrfs_balance+0x312/0xb04
> [ 1355.166778] LR is at btrfs_run_delayed_iputs+0x2d/0xac
> [ 1355.166931] pc : []lr : []psr: 6033
> [ 1355.166931] sp : cb141d98  ip :   fp : be83fdb4
> [ 1355.166931] r10:   r9 :   r8 : 
> [ 1355.184173] r7 :   r6 : ffef  r5 : ede7f000  r4 : ed730e00
> [ 1355.189636] r3 :   r2 :   r1 :   r0 : 0007
> [ 1355.203277] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment 
> user
> [ 1355.203277] Control: 50c5387d  Table: 8b15c04a  DAC: 0015
> [ 1355.203277] Process btrfs (pid: 1798, stack limit = 0xcb1402f8)
> [ 1355.203277] Stack: (0xcb141d98 to 0xcb142000)
> [ 1355.203277] 1d80:   
> c145f944 
> [ 1355.227691] 1da0:     0003 ee478d40 
> 0015 
> [ 1355.227691] 1dc0:       
>  
> [ 1355.253356] 1de0:       
> ede7fcd4 ede7fcd8
> [ 1355.253356] 1e00:      271aee1c 
> 000200da c0160fd5
> [ 1355.253356] 1e20: ed74ec00  d6257680  ed730e00  
> ede7f4e8 ede7fcb0
> [ 1355.279022] 1e40: ede7f000  be83fdb4 c013d489 eec9c118 be83ebf8 
> ed74ec00 eec8a370
> [ 1355.279022] 1e60: d6257680  eec8a528  be83fdb4 c013fc6b 
> 001d 00eb
> [ 1355.279022] 1e80: 0007 0001 e6f7e680 c015cecd cb141ea4  
> cb141ef0 
> [ 1355.296142] 1ea0: cb15c000 01ff   0001  
> eeabaac0 0001
> [ 1355.296142] 1ec0: ed5428c0 c1414788 d6257688 00eb cb141ef0 c016011b 
> cb141ef0 
> [ 1355.321807] 1ee0: 0001 c016018f  0817 0001 271aee1c 
> ede92250 d6257680
> [ 1355.321807] 1f00: be83ebf8 be83ebf8 eec8a528  cb14  
> be83fdb4 c0088075
> [ 1355.321807] 1f20: 4000 c00887ff     
>  
> [ 1355.338928] 1f40:      271aee1c 
> 0003 d6257680
> [ 1355.338928] 1f60: be83ebf8 5000940c d6257680 be83ebf8 5000940c 0003 
>  cb14
> [ 1355.364593] 1f80:  c008885d 0003  be83fec7 0003 
> 0013c478 0036
> [ 1355.364593] 1fa0: c000c5a4 c000c401 be83fec7 0003 0003 5000940c 
> be83ebf8 be83fbf8
> [ 1355.364593] 1fc0: be83fec7 0003 0013c478 0036 0002 b7ad 
> 0001 be83fdb4
> [ 1355.381713] 1fe0: 00024b3d be83ebf0 b7f7 b6ea7f9c 8010 0003 
> 00052d17 00090224
> [ 1355.381713] [] (btrfs_balance+0x312/0xb04) from [] 
> (btrfs_ioctl_balance+0x109/0x174)
> [ 1355.381713] [] (btrfs_ioctl_balance+0x109/0x174) from 
> [] (btrfs_ioctl+0xbf5/0xd42)
> [ 1355.418518] [] (btrfs_ioctl+0xbf5/0xd42) from [] 
> (vfs_ioctl+0xd/0x28)
> [ 1355.418518] [] (vfs_ioctl+0xd/0x28) from [] 
> (do_vfs_ioctl+0x35d/0x38e)
> [ 1355.427093] [] (do_vfs_ioctl+0x35d/0x38e) from [] 
> (sys_ioctl+0x2d/0x44)
> [ 1355.88] [] (sys_ioctl+0x2d/0x44) from [] 
> (ret_fast_syscall+0x1/0x44)
> [ 1355.88] Code: d107 f116 0f11 d100 (de02) 4620 
> [ 1355.458343] ---[ end trace f06b6b8fcd08e6d5 ]---
> 
> A new 'btrfs filesystem balance /' seems to just hang, and is
> unkillable.
> 
> After a reboot, I tried again, with the same result:
> 
> [   81.048767] [ cut here ]
> [   81.053619] kernel BUG at fs/btrfs/volumes.c:2733!
> [   81.053619] Internal error: Oops - BUG: 0 [#1] SMP
> [   81.059295] Modules linked in:
> [   81.059295] CPU: 1Not tainted  (3.3.0 #8)
> [   81.071411] PC is at btrfs_balance+0x312/0xb04
> [   81.074890] LR is at btrfs_run_delayed_iputs+0x2d/0xac
> [   81.074890] pc : []lr : []psr: 6133
> [   81.074890] sp : edda5d98  ip :   fp : beb62d64
> [   81.093475] r10:   r9 :   r8 : 
> [   81.098327] r7 :   r6 : ffef  r5 : ed73f000  r4 : ee311c00
> [   81.098327] r3 :   r2 :   r1 :   r0 : 0007
> [   81.112609] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment 
> user
> [   81.112609] Control: 50c5387d  Table: a7fb404a  DAC: 0015
> [   81.112609] Process btrfs (pid: 752, stack limit = 0xedda42f8)
> [   81.132354] Stack: (0xedda5d98 to 0xedda6000)
> [   81.132354] 5d80:   
> c145f944 
> [   81.145477] 5da0:     0003 eeabca40 
> 0015 000