I have a weird problem concerning 5 btrfs partitions on 3 different disks: My system became slow and started to hang and go, so I shut it down and it hang totally whilst shutting down. With the sysrq shortcut I could kill it and restart. Booting didn''t work any more throwing me into a shell at initramfs. I booted from a CD and tried to mount the first btrfs partition, the system hung up after about 1 sec, just throwing "killed" to the shell. I tried (after reboot) to mount the 4 other partitions which are on different disks: the failure is always the same. I also tried mount options as "degraded", "read-only" w/o success. But btrfsck works flawless, also btrfsctl -A, no crashes. Any other partition on the same disk like ext4 mount perfectly. I tried it with 3 kernels from the 2.5.35 series. My system is a AMD64, so I put one SSD disk as an external drive (USB) to a laptop running a 32bit system, it crashed the same at my wanting to mount the partition. This is my config: $uname -a Linux ubuntu 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC 2010 i686 GNU/Linux Here is a dmesg trace during booting from the CD, it not the crash yet. [ 7.782823] Btrfs loaded [ 7.786081] xor: automatically using best checksumming function: pIII_sse [ 7.804000] pIII_sse : 11626.000 MB/sec [ 7.804001] xor: using function: pIII_sse (11626.000 MB/sec) [ 7.805746] device-mapper: dm-raid45: initialized v0.2594b [ 7.851186] device fsid 3a4b4bc6c07de70b-2b32b3df70d2459f devid 1 transid 407064 /dev/sda2 [ 7.881078] Btrfs detected SSD devices, enabling SSD mode [ 7.923553] ------------[ cut here ]------------ [ 7.923556] kernel BUG at /build/buildd/linux-2.6.35/fs/btrfs/tree-log.c:813! [ 7.923558] invalid opcode: 0000 [#1] SMP [ 7.923561] last sysfs file: /sys/devices/virtual/bdi/btrfs-1/uevent [ 7.923562] Modules linked in: dm_raid45 xor btrfs zlib_deflate crc32c libcrc32c nouveau ttm drm_kms_helper usbhid hid usb_storage drm sky2 firewire_ohci firewire_core intel_agp crc_itu_t ahci pata_jmicron libahci agpgart i2c_algo_bit [ 7.923577] [ 7.923579] Pid: 453, comm: exe Not tainted 2.6.35-22-generic #33-Ubuntu P5K-E/P5K-E [ 7.923582] EIP: 0060:[<f9c44024>] EFLAGS: 00010246 CPU: 0 [ 7.923590] EIP is at add_inode_ref+0x3f4/0x410 [btrfs] [ 7.923592] EAX: 00000000 EBX: 00000097 ECX: 00000000 EDX: 00000274 [ 7.923594] ESI: 00000002 EDI: f6fe8af0 EBP: c1257c30 ESP: c1257bd4 [ 7.923596] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 7.923598] Process exe (pid: 453, ti=c1256000 task=f6a30000 task.ti=c1256000) [ 7.923599] Stack: [ 7.923600] c1257be8 c1257be8 c0132ba6 f6fe8af0 00000011 c1257bf0 f9c2d2c1 c1257c30 [ 7.923605] <0> f9c21d37 c1257c20 00000000 f6f9b000 f643887c 00000004 00000000 f6fe8af0 [ 7.923610] <0> f68e6000 f7156000 fffb6000 fffb6000 00000097 00000002 f6fe8af0 c1257c94 [ 7.923615] Call Trace: [ 7.923620] [<c0132ba6>] ? kunmap_atomic+0x66/0x80 [ 7.923628] [<f9c2d2c1>] ? unmap_extent_buffer+0x11/0x20 [btrfs] [ 7.923637] [<f9c21d37>] ? btrfs_item_size+0xc7/0xd0 [btrfs] [ 7.923644] [<f9c45a46>] ? replay_one_buffer+0x246/0x320 [btrfs] [ 7.923651] [<f9c423a9>] ? walk_down_log_tree+0x219/0x3b0 [btrfs] [ 7.923658] [<f9c425e9>] ? walk_log_tree+0xa9/0x1d0 [btrfs] [ 7.923665] [<f9c44d94>] ? btrfs_recover_log_trees+0x1d4/0x2b0 [btrfs] [ 7.923672] [<f9c45800>] ? replay_one_buffer+0x0/0x320 [btrfs] [ 7.923680] [<f9c0d07c>] ? open_ctree+0x101c/0x14c0 [btrfs] [ 7.923686] [<f9bee672>] ? btrfs_fill_super+0x52/0x110 [btrfs] [ 7.923690] [<c0356069>] ? strlcpy+0x39/0x50 [ 7.923695] [<f9beebbd>] ? btrfs_get_sb+0x24d/0x2d0 [btrfs] [ 7.923699] [<c020f66f>] ? __alloc_percpu+0xf/0x20 [ 7.923701] [<c0231109>] ? alloc_vfsmnt+0xf9/0x130 [ 7.923704] [<c021aee4>] ? vfs_kern_mount+0x74/0x1c0 [ 7.923707] [<c022f493>] ? get_fs_type+0x33/0xb0 [ 7.923709] [<c021b08e>] ? do_kern_mount+0x3e/0xe0 [ 7.923711] [<c023260c>] ? do_mount+0x1dc/0x220 [ 7.923714] [<c02326bb>] ? sys_mount+0x6b/0xa0 [ 7.923717] [<c05c90a4>] ? syscall_call+0x7/0xb [ 7.923718] Code: e8 42 b3 fa ff 8b 45 d4 e8 5a 87 5e c6 8b 45 cc e8 52 87 5e c6 31 c0 83 c4 50 5b 5e 5f 5d c3 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe <0f> 0b eb fe 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe 8d b6 00 00 00 [ 7.923746] EIP: [<f9c44024>] add_inode_ref+0x3f4/0x410 [btrfs] SS:ESP 0068:c1257bd4 [ 7.923755] ---[ end trace 2b634c981d89a441 ]--- Any help how to get my data off those disk is seriously appreciated. -- 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
I did an btrfs-image -c 9 dump on one partition, but it generated 142MB of data. How can I send this? -- 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
> I tried it with 3 kernels from the 2.5.35 series. > My system is a AMD64, so I put one SSD disk as an external drive (USB) to a > laptop running a 32bit system, it crashed the same at my wanting to mount the > partition. > > This is my config: > $uname -a > Linux ubuntu 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC 2010 i686 > GNU/LinuxYou could try: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.36-rc7-maverick/ -- Tomasz Chmielewski http://wpkg.org -- 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
Tomasz Chmielewski <mangoo <at> wpkg.org> writes:> > You could try: > > http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.36-rc7-maverick/ >Alright I tried 2.6.36-rc7 to no avail, same crashing behaviour. This is a kernel trace (from Intel-Atom netbook => 32bit) at which the machine freezes after trying to mount the btrfs SSD drive: ----trace--- Pid: 1882, comm: mount Tainted: G D 2.6.36-020636rc7-generic EIP: 0060:[>f81039ef>] EFLAGS: 00010283 CPU:0 EIP is at btrfs_test_super+0xf/0x30 [btrfs] EAX: 000000000 EBX: e2e6ca00 ECX: c0221090 EDX: f1689b80 ESI: f81039e0 EDI: f816d318 EBP: d3001e78 ESP: d300115c DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 068 Process mount (pid: 1882, ti=d3000000 task=ef54cc20 task.ti=d300000000) Stack: c02221af c0221090 f816d300 00000000 fffffff3 00000000 f6eb7a00 d3001ee8 <0> f8103e28 f1689b80 d3001ea8 d3001eb4 e62670c0 00000000 eee22b00 00000000 <0> f816d300 00000000 000000d0 00000000 00000000 e0a18e00 f1689b80 00000004 Call Trace: [<c02221af>] ? sget+0x3f/0x1f0 [<c0221090>] ? set_anon_super+0x0/0xe0 [<f8103e28>] ? btrfs_get_sb+0x108/0x2c0 [btrfs] [<c021671f>] ? __alloc_percpu+0xf/0x20 [<c0221f4e>] ? vfs_kern_mount+0x6e/0x1b0 [<c0235bb5>] ? get_fs_type+0x35/0xa0 [<c02220ee>] ? do_kern_mount+0x3e/0x80 [<c0238869>] ? do_new_mount+0x69/0xa0 [<c0238b48>] ? do_mount+0x188/0x1a0 [<c0238bcd>] ? sys_mount+0x6d/0xa0 [<c0102cdf>] ? sysenter_do_call+0x12/0x28 Code: eb dc ba c0 02 00 00 b8 34 6d 16 f8 e8 1b ab 04 c8 eb d6 89 f6 8d bc 27 00 00 00 00 55 89 e5 0f 1f 44 00 00 8b 80 7c 01 00 00 5d <8b> 80 14 01 00 00 39 90 ec 1d 00 00 0f 94 c0 0f b6 c0 c3 8d b4 EIP: [<f71039ef>] btrfs_test_super+0xf/0x30 [btrfs] SS:ESP 0068:d3001e5c CR2: 0000000000000114 ---[ end trace ]--- -- 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
So this is a completely different race from the first one. Do you get the same crashes every time you try to boot or are they different every time? We can definitely help get the data off. -chris On Fri, Oct 08, 2010 at 04:49:11PM +0000, Gerhard Kulzer wrote:> Tomasz Chmielewski <mangoo <at> wpkg.org> writes: > > > > > You could try: > > > > http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.36-rc7-maverick/ > > > > Alright I tried 2.6.36-rc7 to no avail, same crashing behaviour. > > This is a kernel trace (from Intel-Atom netbook => 32bit) at which > the machine freezes after trying to mount the btrfs SSD drive: > > ----trace--- > Pid: 1882, comm: mount Tainted: G D 2.6.36-020636rc7-generic > EIP: 0060:[>f81039ef>] EFLAGS: 00010283 CPU:0 > EIP is at btrfs_test_super+0xf/0x30 [btrfs] > EAX: 000000000 EBX: e2e6ca00 ECX: c0221090 EDX: f1689b80 > ESI: f81039e0 EDI: f816d318 EBP: d3001e78 ESP: d300115c > DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 068 > Process mount (pid: 1882, ti=d3000000 task=ef54cc20 task.ti=d300000000) > Stack: > c02221af c0221090 f816d300 00000000 fffffff3 00000000 f6eb7a00 d3001ee8 > <0> f8103e28 f1689b80 d3001ea8 d3001eb4 e62670c0 00000000 eee22b00 00000000 > <0> f816d300 00000000 000000d0 00000000 00000000 e0a18e00 f1689b80 00000004 > Call Trace: > [<c02221af>] ? sget+0x3f/0x1f0 > [<c0221090>] ? set_anon_super+0x0/0xe0 > [<f8103e28>] ? btrfs_get_sb+0x108/0x2c0 [btrfs] > [<c021671f>] ? __alloc_percpu+0xf/0x20 > [<c0221f4e>] ? vfs_kern_mount+0x6e/0x1b0 > [<c0235bb5>] ? get_fs_type+0x35/0xa0 > [<c02220ee>] ? do_kern_mount+0x3e/0x80 > [<c0238869>] ? do_new_mount+0x69/0xa0 > [<c0238b48>] ? do_mount+0x188/0x1a0 > [<c0238bcd>] ? sys_mount+0x6d/0xa0 > [<c0102cdf>] ? sysenter_do_call+0x12/0x28 > Code: eb dc ba c0 02 00 00 b8 34 6d 16 f8 e8 1b ab 04 c8 eb d6 89 f6 > 8d bc 27 00 00 00 00 55 89 e5 0f 1f 44 00 00 8b 80 7c 01 00 00 5d > <8b> 80 14 01 00 00 39 90 ec 1d 00 00 0f 94 c0 0f b6 c0 c3 8d b4 > EIP: [<f71039ef>] btrfs_test_super+0xf/0x30 [btrfs] SS:ESP 0068:d3001e5c > CR2: 0000000000000114 > ---[ end trace ]--- > > > -- > 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-- 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
Chris Mason <chris.mason <at> oracle.com> writes:> > So this is a completely different race from the first one. Do you get > the same crashes every time you try to boot or are they different every > time? > > We can definitely help get the data off. > > -chris >Thanks Chris, the first trace was from dmesg during boot where it actually did not mount the btrfs partition but just "saw" it during boot. The system continued running. The last trace is the one that occurs when I try to mount the system, and it dies with it. -- 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
On Thu, Oct 07, 2010 at 02:12:33PM +0000, Gerhard Kulzer wrote:> I have a weird problem concerning 5 btrfs partitions on 3 different disks: > My system became slow and started to hang and go, so I shut it down and it > hang totally whilst shutting down. With the sysrq shortcut I could kill it > and restart. > > Booting didn''t work any more throwing me into a shell at initramfs.Ok, I''d like to go through each of these btrfs partitions one at a time.> Here is a dmesg trace during booting from the CD, it not the crash yet. > > [ 7.782823] Btrfs loaded > [ 7.786081] xor: automatically using best checksumming function: pIII_sse > [ 7.804000] pIII_sse : 11626.000 MB/sec > [ 7.804001] xor: using function: pIII_sse (11626.000 MB/sec) > [ 7.805746] device-mapper: dm-raid45: initialized v0.2594b > [ 7.851186] device fsid 3a4b4bc6c07de70b-2b32b3df70d2459f devid 1 transid > 407064 /dev/sda2 > [ 7.881078] Btrfs detected SSD devices, enabling SSD mode > [ 7.923553] ------------[ cut here ]------------ > [ 7.923556] kernel BUG at /build/buildd/linux-2.6.35/fs/btrfs/tree-log.c:813! > [ 7.923558] invalid opcode: 0000 [#1] SMP^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Once you see kernel BUG() that''s the crash ;) This isn''t from the btrfs scan, this is from mounting the FS. Could you please mount the filesystems one at a time and see if they all fail or of it is just this one. -chris -- 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
Chris Mason <chris.mason <at> oracle.com> writes:> > [ 7.881078] Btrfs detected SSD devices, enabling SSD mode > > [ 7.923553] ------------[ cut here ]------------ > > [ 7.923556] kernel BUG at /build/buildd/linux-2.6.35/fs/btrfs/tree-log.c:813!> > [ 7.923558] invalid opcode: 0000 [#1] SMP > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Once you see kernel BUG() that''s the crash ;) > > This isn''t from the btrfs scan, this is from mounting the FS. Could you > please mount the filesystems one at a time and see if they all fail or > of it is just this one. > > -chris > --Ahh big surprise, I can mount my other btrfs partitions (4 on 2 HDD) all of a sudden. I wonder why, because I tried before and I got a crash with all of them. The only difference now is that I took the SSD with the 5th partition out. I have a boot partition as ext4 on that same SSD drive which I can mount w/o problems. So I think it''s not the SSD itself that is buggy. -- 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
Gerhard Kulzer <gerhard <at> kulzer.net> writes:> > Chris Mason <chris.mason <at> oracle.com> writes: > > > > [ 7.881078] Btrfs detected SSD devices, enabling SSD mode > > > [ 7.923553] ------------[ cut here ]------------ > > > [ 7.923556] kernel BUG at /build/buildd/linux-2.6.35/fs/btrfs > /tree-log.c:813! > > > [ 7.923558] invalid opcode: 0000 [#1] SMP > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Once you see kernel BUG() that''s the crash ;) > > > > This isn''t from the btrfs scan, this is from mounting the FS. Could you > > please mount the filesystems one at a time and see if they all fail or > > of it is just this one. > > > > -chris > > -- > Ahh big surprise, I can mount my other btrfs partitions (4 on 2 HDD) all of a > sudden. > I wonder why, because I tried before and I got a crash with all of them. > The only difference now is that I took the SSD with the 5th partition out. > I have a boot partition as ext4 on that same SSD drive which I can mount > w/o problems. So I think it''s not the SSD itself that is buggy. >Ok, I understand a bit more now. a) when I boot my system from CD and the faulty SSD btrfs is physically present, then there''s a little hick-up during boot resulting in my first trace and the system crashes if I subsequently mount ANY other btrfs partition. b) If I boot w/o the SSD, then there is no hick-up and I can mount all remaining btrfs partitions w/o crash and the data is there. Gerhard -- 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
On Sat, Oct 09, 2010 at 01:08:40PM +0000, Gerhard Kulzer wrote:> Gerhard Kulzer <gerhard <at> kulzer.net> writes: > > > > > Chris Mason <chris.mason <at> oracle.com> writes: > > > > > > [ 7.881078] Btrfs detected SSD devices, enabling SSD mode > > > > [ 7.923553] ------------[ cut here ]------------ > > > > [ 7.923556] kernel BUG at /build/buildd/linux-2.6.35/fs/btrfs > > /tree-log.c:813! > > > > [ 7.923558] invalid opcode: 0000 [#1] SMP > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > Once you see kernel BUG() that''s the crash ;) > > > > > > This isn''t from the btrfs scan, this is from mounting the FS. Could you > > > please mount the filesystems one at a time and see if they all fail or > > > of it is just this one. > > > > > > -chris > > > -- > > Ahh big surprise, I can mount my other btrfs partitions (4 on 2 HDD) all of a > > sudden. > > I wonder why, because I tried before and I got a crash with all of them. > > The only difference now is that I took the SSD with the 5th partition out. > > I have a boot partition as ext4 on that same SSD drive which I can mount > > w/o problems. So I think it''s not the SSD itself that is buggy. > > > > Ok, I understand a bit more now. > a) when I boot my system from CD and the faulty SSD btrfs is physically present, > then there''s a little hick-up during boot resulting in my first trace and the > system crashes if I subsequently mount ANY other btrfs partition. > b) If I boot w/o the SSD, then there is no hick-up and I can mount all remaining > btrfs partitions w/o crash and the data is there.Ok, so tell me more about the SSD with the btrfs-of-death. Is it a multi-device SSD? -chris -- 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
Chris Mason <chris.mason <at> oracle.com> writes:> > Ok, so tell me more about the SSD with the btrfs-of-death. Is it a > multi-device SSD? > > -chris >Its a single device Intel X25-M G2 Postville 80GB -Gerhard -- 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
On Tue, Oct 12, 2010 at 06:44:13AM +0000, Gerhard Kulzer wrote:> Chris Mason <chris.mason <at> oracle.com> writes: > > > > > > Ok, so tell me more about the SSD with the btrfs-of-death. Is it a > > multi-device SSD? > > > > -chris > > > Its a single device Intel X25-M G2 Postville 80GBOk, if you can confirm this is the very first oops you see: [ 7.923556] kernel BUG at /build/buildd/linux-2.6.35/fs/btrfs/tree-log.c:813! I''ve got a utility that will wipe the log and get you mountable again. The intel drive should definitely support barriers, are you doing anything with LVM or raid or dm-crypt on top of it? -chris -- 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
On Wed, Oct 13, 2010 at 02:49, Chris Mason <chris.mason@oracle.com> wrote: [...]> > I''ve got a utility that will wipe the log and get you mountable again. > The intel drive should definitely support barriers, are you doing > anything with LVM or raid or dm-crypt on top of it? >Not Intel related and I don''t use dm-crypt, but I use btrfs on three machines over RAID 1 (MD) + LVM, all with SATA disks (and I''ve learned the lesson: write caching disabled on all drives). Are there ill effects to such setups? -- Francis Galiegue, fgaliegue@gmail.com "It seems obvious [...] that at least some ''business intelligence'' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (Stéphane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) -- 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
Chris Mason <chris.mason <at> oracle.com> writes:> > Its a single device Intel X25-M G2 Postville 80GB > > Ok, if you can confirm this is the very first oops you see: > > kernel BUG at /build/buildd/linux-2.6.35/fs/btrfs/tree-log.c:813! > > I''ve got a utility that will wipe the log and get you mountable again. > The intel drive should definitely support barriers, are you doing > anything with LVM or raid or dm-crypt on top of it? >I think somebody replied in my place... I don''t use any lvm or raid or dm_crypt, just 1 straight partition formatted as btrfs. Gerhard -- 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
Hi There, I got the same problem (freezing kernel while mounting btfs disk). My block device is a 8gb sdcard, it should be physical intact cause i can dd the card into a file without problems. Here is what i did so far: mount mmcblk0 under 2.6.35 (freeze) mount the diskdumped image as a loop device on another system using 2.6.35 and current git kernel (freeze) so i''m pretty much lost a.t.m. I''m willing to send the metadata image (instructions please) and Chris could you please send me your wipe-log tool so i can maybee restore my data files ;) greetings erik -- 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