Re: Failure to remove snapshot with 3.12* and FS switches to read-only
On Mon, Sep 23, 2013 at 02:54:17PM +0200, Mathieu Chouquet-Stringer wrote: My system is configured to do FS snapshots when I upgrade packages. I have a cron job which runs at night to delete these snapshots. Its goal is to keep 10 snapshots maximum, one per day if possible. This works perfectly with 3.11.1 but fails miserably with anything post 3.11. With a pre 3.12 (3.11.0-10050-g3711d86), this is what happens: [...] And this doesn't seem to happen anymore with 3.12-rc2, sorry for the noise. -- Mathieu Chouquet-Stringer m+bt...@thi.eu.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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
Failure to remove snapshot with 3.12* and FS switches to read-only
[816476de] ? do_page_fault+0xe/0x10 [8164bce9] system_call_fastpath+0x16/0x1b ---[ end trace 9cdf8449ae3d9eb4 ]--- BTRFS error (device dm-1) in btrfs_ioctl_snap_destroy:2252: errno=-22 unknown BTRFS info (device dm-1): forced readonly I haven't yet tried to reproduce it manually but can certainly do so. Note my FS is clean as a scrub doesn't return any error. If I can do anything to help, let me know. Cheers, -- Mathieu Chouquet-Stringer m+bt...@thi.eu.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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
Failure to remove snapshot with 3.12* and FS switches to read-only
[816476de] ? do_page_fault+0xe/0x10 [8164bce9] system_call_fastpath+0x16/0x1b ---[ end trace 9cdf8449ae3d9eb4 ]--- BTRFS error (device dm-1) in btrfs_ioctl_snap_destroy:2252: errno=-22 unknown BTRFS info (device dm-1): forced readonly I haven't yet tried to reproduce it manually but can certainly do so. Note my FS is clean as a scrub doesn't return any error. If I can do anything to help, let me know. Cheers, -- Mathieu Chouquet-Stringer m+bt...@thi.eu.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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: GPF in read_extent_buffer while scrubbing on 3.7.0-rc8-00014-g27d7c2a
Hi, Anyone has any idea about what I should try next regarding this bug? On Mon, Dec 10, 2012 at 11:21:25PM +0100, Mathieu Chouquet-Stringer wrote: after enabling page alloc and slub debug, I was able to capture an error followed by the usual GPF. More below. On Thu, Dec 06, 2012 at 03:34:58PM +0100, Mathieu Chouquet-Stringer wrote: Using the last couple of kernels (3.6 or 3.7), scrubbing my btrfs fs (which is on a luks based lvm device) will always end up crashing my pc. [...] The warning: WARNING: at fs/btrfs/extent_io.c:4680 read_extent_buffer+0xee/0x120() Hardware name: 2392CTO Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT lockd sunrpc nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack rfcomm bnep arc4 iwldvm mac80211 iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek coretemp kvm_intel kvm microcode uvcvideo videobuf2_vmalloc videobuf2_memops pcspkr videobuf2_core videodev btusb media i2c_i801 bluetooth snd_hda_intel snd_hda_codec cdc_ncm usbnet mii cdc_wdm cdc_acm snd_hwdep snd_seq snd_seq_device snd_pcm lpc_ich mfd_core iwlwifi cfg80211 e1000e snd_page_alloc mei snd_timer thinkpad_acpi snd soundcore rfkill uinput dm_crypt crc32c_intel nouveau ghash_clmulni_intel mxm_wmi ttm i915 i2c_algo_bit drm_kms_helper firewire_ohci drm sdhci_pci firewire_core sdhci mmc_core crc_itu_t i2c_core wmi video Pid: 536, comm: btrfs-endio-met Not tainted 3.7.0-rc8-00039-ged23ec4 #4 Call Trace: [8104bebf] warn_slowpath_common+0x7f/0xc0 [8104bf1a] warn_slowpath_null+0x1a/0x20 [812aae9e] read_extent_buffer+0xee/0x120 [812a1bb2] btrfs_node_key+0x22/0x30 [812dd720] __readahead_hook.isra.5+0x3a0/0x3f0 [812ddb14] btree_readahead_hook+0x24/0x40 [81286069] btree_readpage_end_io_hook+0x139/0x290 [812a6ff3] end_bio_extent_readpage+0xd3/0xa40 [812853a6] ? end_workqueue_fn+0x36/0x50 [811b27ed] bio_endio+0x1d/0x30 [812853b1] end_workqueue_fn+0x41/0x50 [812b5916] worker_loop+0x136/0x580 [812b57e0] ? btrfs_queue_worker+0x300/0x300 [8106f480] kthread+0xc0/0xd0 [8106f3c0] ? kthread_create_on_node+0x120/0x120 [8168e8ec] ret_from_fork+0x7c/0xb0 [8106f3c0] ? kthread_create_on_node+0x120/0x120 gdb says it's this WARN ON: (gdb) l *(read_extent_buffer + 0xee) 0x726e is in read_extent_buffer (fs/btrfs/extent_io.c:4680). 4675char *kaddr; 4676char *dst = (char *)dstv; 4677size_t start_offset = eb-start ((u64)PAGE_CACHE_SIZE - 1); 4678unsigned long i = (start_offset + start) PAGE_CACHE_SHIFT; 4679 4680WARN_ON(start eb-len); 4681WARN_ON(start + len eb-start + eb-len); 4682 4683offset = (start_offset + start) ((unsigned long)PAGE_CACHE_SIZE - 1); 4684 The GPF which follows right after is: general protection fault: [#1] SMP DEBUG_PAGEALLOC Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT lockd sunrpc nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack rfcomm bnep arc4 iwldvm mac80211 iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek coretemp kvm_intel kvm microcode uvcvideo videobuf2_vmalloc videobuf2_memops pcspkr videobuf2_core videodev btusb media i2c_i801 bluetooth snd_hda_intel snd_hda_codec cdc_ncm usbnet mii cdc_wdm cdc_acm snd_hwdep snd_seq snd_seq_device snd_pcm lpc_ich mfd_core iwlwifi cfg80211 e1000e snd_page_alloc mei snd_timer thinkpad_acpi snd soundcore rfkill uinput dm_crypt crc32c_intel nouveau ghash_clmulni_intel mxm_wmi ttm i915 i2c_algo_bit drm_kms_helper firewire_ohci drm sdhci_pci firewire_core sdhci mmc_core crc_itu_t i2c_core wmi video CPU 1 Pid: 536, comm: btrfs-endio-met Tainted: GW 3.7.0-rc8-00039-ged23ec4 #4 LENOVO 2392CTO/2392CTO RIP: 0010:[8136c756] [8136c756] memcpy+0x6/0x110 RSP: 0018:8804215a9b70 EFLAGS: 00010207 RAX: 8804215a9c57 RBX: 0011 RCX: 0011 RDX: 0011 RSI: 00050803 RDI: 8804215a9c57 RBP: 8804215a9bb8 R08: R09: 0486 R10: 0001 R11: 00aa R12: 8804215a9c68 R13: 8803f4c5cfc0 R14: 0048 R15: 0011 FS: () GS:88043e24() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fe992197000 CR3: 01c0b000 CR4: 001407e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400
Re: GPF in read_extent_buffer while scrubbing on 3.7.0-rc8-00014-g27d7c2a
Hi again, after enabling page alloc and slub debug, I was able to capture an error followed by the usual GPF. More below. On Thu, Dec 06, 2012 at 03:34:58PM +0100, Mathieu Chouquet-Stringer wrote: Using the last couple of kernels (3.6 or 3.7), scrubbing my btrfs fs (which is on a luks based lvm device) will always end up crashing my pc. [...] The warning: WARNING: at fs/btrfs/extent_io.c:4680 read_extent_buffer+0xee/0x120() Hardware name: 2392CTO Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT lockd sunrpc nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack rfcomm bnep arc4 iwldvm mac80211 iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek coretemp kvm_intel kvm microcode uvcvideo videobuf2_vmalloc videobuf2_memops pcspkr videobuf2_core videodev btusb media i2c_i801 bluetooth snd_hda_intel snd_hda_codec cdc_ncm usbnet mii cdc_wdm cdc_acm snd_hwdep snd_seq snd_seq_device snd_pcm lpc_ich mfd_core iwlwifi cfg80211 e1000e snd_page_alloc mei snd_timer thinkpad_acpi snd soundcore rfkill uinput dm_crypt crc32c_intel nouveau ghash_clmulni_intel mxm_wmi ttm i915 i2c_algo_bit drm_kms_helper firewire_ohci drm sdhci_pci firewire_core sdhci mmc_core crc_itu_t i2c_core wmi video Pid: 536, comm: btrfs-endio-met Not tainted 3.7.0-rc8-00039-ged23ec4 #4 Call Trace: [8104bebf] warn_slowpath_common+0x7f/0xc0 [8104bf1a] warn_slowpath_null+0x1a/0x20 [812aae9e] read_extent_buffer+0xee/0x120 [812a1bb2] btrfs_node_key+0x22/0x30 [812dd720] __readahead_hook.isra.5+0x3a0/0x3f0 [812ddb14] btree_readahead_hook+0x24/0x40 [81286069] btree_readpage_end_io_hook+0x139/0x290 [812a6ff3] end_bio_extent_readpage+0xd3/0xa40 [812853a6] ? end_workqueue_fn+0x36/0x50 [811b27ed] bio_endio+0x1d/0x30 [812853b1] end_workqueue_fn+0x41/0x50 [812b5916] worker_loop+0x136/0x580 [812b57e0] ? btrfs_queue_worker+0x300/0x300 [8106f480] kthread+0xc0/0xd0 [8106f3c0] ? kthread_create_on_node+0x120/0x120 [8168e8ec] ret_from_fork+0x7c/0xb0 [8106f3c0] ? kthread_create_on_node+0x120/0x120 gdb says it's this WARN ON: (gdb) l *(read_extent_buffer + 0xee) 0x726e is in read_extent_buffer (fs/btrfs/extent_io.c:4680). 4675char *kaddr; 4676char *dst = (char *)dstv; 4677size_t start_offset = eb-start ((u64)PAGE_CACHE_SIZE - 1); 4678unsigned long i = (start_offset + start) PAGE_CACHE_SHIFT; 4679 4680WARN_ON(start eb-len); 4681WARN_ON(start + len eb-start + eb-len); 4682 4683offset = (start_offset + start) ((unsigned long)PAGE_CACHE_SIZE - 1); 4684 The GPF which follows right after is: general protection fault: [#1] SMP DEBUG_PAGEALLOC Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT lockd sunrpc nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack rfcomm bnep arc4 iwldvm mac80211 iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek coretemp kvm_intel kvm microcode uvcvideo videobuf2_vmalloc videobuf2_memops pcspkr videobuf2_core videodev btusb media i2c_i801 bluetooth snd_hda_intel snd_hda_codec cdc_ncm usbnet mii cdc_wdm cdc_acm snd_hwdep snd_seq snd_seq_device snd_pcm lpc_ich mfd_core iwlwifi cfg80211 e1000e snd_page_alloc mei snd_timer thinkpad_acpi snd soundcore rfkill uinput dm_crypt crc32c_intel nouveau ghash_clmulni_intel mxm_wmi ttm i915 i2c_algo_bit drm_kms_helper firewire_ohci drm sdhci_pci firewire_core sdhci mmc_core crc_itu_t i2c_core wmi video CPU 1 Pid: 536, comm: btrfs-endio-met Tainted: GW3.7.0-rc8-00039-ged23ec4 #4 LENOVO 2392CTO/2392CTO RIP: 0010:[8136c756] [8136c756] memcpy+0x6/0x110 RSP: 0018:8804215a9b70 EFLAGS: 00010207 RAX: 8804215a9c57 RBX: 0011 RCX: 0011 RDX: 0011 RSI: 00050803 RDI: 8804215a9c57 RBP: 8804215a9bb8 R08: R09: 0486 R10: 0001 R11: 00aa R12: 8804215a9c68 R13: 8803f4c5cfc0 R14: 0048 R15: 0011 FS: () GS:88043e24() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fe992197000 CR3: 01c0b000 CR4: 001407e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process btrfs-endio-met (pid: 536, threadinfo 8804215a8000, task 8804224eb0e0) Stack: 812aae73 8804105ea000 8003 1000 8804215a9c20 03dd 88041232a7c0 8804215a9c20
GPF in read_extent_buffer while scrubbing on 3.7.0-rc8-00014-g27d7c2a
Hello, Using the last couple of kernels (3.6 or 3.7), scrubbing my btrfs fs (which is on a luks based lvm device) will always end up crashing my pc. The error (screenshot: http://mathieu.csetco.com/btrfs-scrub-crash.jpeg) looks very similar to this crash (that's why I'm Cc'ing Sami): btrfs GPF in read_extent_buffer() while scrubbing with kernel 3.4.2 http://marc.info/?t=13412707662r=1w=2 (I transcribed this from the picture) Pid: 518, comm: btrfs-endio-met Tainted: G W3.7.0-rc8-00014-g27d7c2a RIP: 0010:[f8136c186] [8136c186] memcpy+0x6/0x110 [...] Call Trace: [812aa8a3] ? read_extent_buffer+0xc3/0x120 [812a15e2] btrfs_node_key+0x22/0x30 [812dd150] __readahead_hook.isra.5+0x3a0/0x3f0 [812dd544] btree_readahead_hook+0x24/0x40 [81285a99] btree_readpage_end_io_hook+0x139/0x290 [...] Looking at the email thread, I can't seem to be able to find a happy ending. It looks like this could still be open. Here's my btrfs device: Label: none uuid: 02c68790-78a5-418a-901c-59eda67b0e6e Total devices 1 FS bytes used 197.60GB devid1 size 460.41GB used 289.07GB path /dev/dm-2 The output of fi df /: Data: total=269.00GB, used=195.88GB System, DUP: total=32.00MB, used=32.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=10.00GB, used=1.71GB Anything I could do to help diagnose the issue? I've seen Chris suggested to enable slub (I use slub, not slab) and pagealloc debug. What else? -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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
Error: btrfs bad tree block
Hello, It seems BTRFS finally gave up on me! :-) I've been using as my main FS for quite a while and this time I'm not able to fix this issue. I've tried mounting with -o clear_cache, zeroing the log and changing super but I'm still getting this over and over: btrfs bad tree block start 0 204055724032 This is running 3.2.0-rc6-5-ga36bfdd I've tried btrfsck but it segfaults haha... I didn't do anything special before that except I had a bunch of subvolumes and I deleted them. Any idea what I could try next? Thanks in advance, -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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: Error: btrfs bad tree block
On Mon, Dec 19, 2011 at 01:33:05PM +0100, Mathieu Chouquet-Stringer wrote: Any idea what I could try next? Or fsck I could use? ;-) -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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: Btrfs bug with g38867a2 and a question
On Fri, Sep 23, 2011 at 10:49:22AM -0400, Josef Bacik wrote: Ok I have no idea how this could happen. Can you mount -o clear_cache and see if it's just the cache that's bad? Thanks, Did that and got this (it's a never ending story, this is from a F16 alpha boot cd hence stack trace could be different): [ 512.455253] [ cut here ] [ 512.455464] kernel BUG at fs/btrfs/inode.c:4586! [ 512.455662] invalid opcode: [#1] SMP [ 512.455874] CPU 1 [ 512.455879] Modules linked in: btrfs zlib_deflate libcrc32c xts lrw gf128mul sha256_generic dm_crypt dm_round_robin dm_multipath linear raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 raid0 iscsi_ibft iscsi_boot_sysfs pcspkr edd iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi cramfs arc4 firewire_ohci firewire_core sdhci_pci sdhci yenta_socket crc_itu_t mmc_core iwl4965 iwl_legacy mac80211 cfg80211 rfkill nouveau ttm drm_kms_helper drm i2c_algo_bit i2c_core mxm_wmi wmi video e1000e squashfs [ 512.456018] [ 512.456018] Pid: 1349, comm: mount Not tainted 3.0.0-1.fc16.x86_64 #1 LENOVO 6458V5C/6458V5C [ 512.456018] RIP: 0010:[a036132f] [a036132f] btrfs_add_link+0x123/0x17c [btrfs] [ 512.456018] RSP: 0018:880123e09848 EFLAGS: 00010282 [ 512.456018] RAX: ffef RBX: 8801194c9d78 RCX: 0046 [ 512.456018] RDX: 0127 RSI: 88012aa7aaf0 RDI: 0282 [ 512.456018] RBP: 880123e098b8 R08: 8801228ac000 R09: 005a [ 512.456018] R10: 880123e096d8 R11: 88013b4023c0 R12: 8801194ca610 [ 512.456018] R13: 8801165d2090 R14: 000b R15: 8801181fd630 [ 512.456018] FS: 7f7bb600a820() GS:88013bc0() knlGS: [ 512.456018] CS: 0010 DS: ES: CR0: 8005003b [ 512.456018] CR2: 7f7235313768 CR3: 000113f09000 CR4: 06e0 [ 512.456018] DR0: DR1: DR2: [ 512.456018] DR3: DR6: 0ff0 DR7: 0400 [ 512.456018] Process mount (pid: 1349, threadinfo 880123e08000, task 88012aa7a3e0) [ 512.456018] Stack: [ 512.456018] 88010001 00018028 880123e09888 8801194bb000 [ 512.456018] 5aff8801165b3000 01001537 [ 512.456018] 1000 8801194ba1b0 8801194ca610 880123e099d7 [ 512.456018] Call Trace: [ 512.456018] [a0382862] add_inode_ref+0x2e6/0x37c [btrfs] [ 512.456018] [a037547a] ? read_extent_buffer+0xc3/0xe3 [btrfs] [ 512.456018] [a0383208] replay_one_buffer+0x197/0x212 [btrfs] [ 512.456018] [a0381068] walk_up_log_tree+0xe4/0x1aa [btrfs] [ 512.456018] [a0383071] ? replay_one_dir_item+0xbd/0xbd [btrfs] [ 512.456018] [a038148d] walk_log_tree+0x9e/0x19e [btrfs] [ 512.456018] [a0384562] btrfs_recover_log_trees+0x28b/0x298 [btrfs] [ 512.456018] [a0383071] ? replay_one_dir_item+0xbd/0xbd [btrfs] [ 512.456018] [a0355c42] open_ctree+0x11aa/0x14b8 [btrfs] [ 512.456018] [a033b908] btrfs_mount+0x233/0x498 [btrfs] [ 512.456018] [810f3ef3] ? free_pages+0x47/0x4c [ 512.456018] [8113ddac] mount_fs+0x69/0x155 [ 512.456018] [81107e68] ? __alloc_percpu+0x10/0x12 [ 512.456018] [81152ee6] vfs_kern_mount+0x63/0xa0 [ 512.456018] [81153bba] do_kern_mount+0x4d/0xdf [ 512.456018] [81155250] do_mount+0x63c/0x69f [ 512.456018] [81155534] sys_mount+0x88/0xc2 [ 512.456018] [814e4fc2] system_call_fastpath+0x16/0x1b [ 512.456018] Code: 89 f1 4c 89 fa 4c 89 ee 48 89 44 24 08 41 8b 04 24 66 c1 e8 0c 83 e0 0f 0f b6 80 b8 bd 39 a0 89 04 24 e8 db cf fe ff 85 c0 74 02 0f 0b 45 01 f6 4d 63 f6 4c 03 b3 a0 01 00 00 4c 89 b3 a0 01 00 [ 512.456018] RIP [a036132f] btrfs_add_link+0x123/0x17c [btrfs] [ 512.456018] RSP 880123e09848 [ 512.485056] ---[ end trace cea880cef8a5d83b ]--- -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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: Btrfs bug with g38867a2 and a question
On Fri, Sep 23, 2011 at 11:34:40AM -0400, Josef Bacik wrote: Yeah this is a different problem that's fixed upstream, so reboot into your other newer kernel with -o clear_cache. Thanks, Ok I'm back in business now, thanks... Now I'll try to understand why my pc sometimes hangs doing write IOs... -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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: Btrfs bug with g38867a2 and a question
On Thu, Sep 22, 2011 at 01:10:55AM +0200, David Sterba wrote: please prefix printk messages with btrfs: Well my computer crashed before I could reboot with the newly compiled kernel. And now it bugs while it tries to mount the kernel meaning my computer is fscked! :-) Bug at fs/btrfs/free-space-cache.c:1327 (I have a screenshot if needed) function remove_from_bitmap /* * XXX - this can go away after a few releases. * * since the only user of btrfs_remove_free_space is the tree logging * stuff, and the only way to test that is under crash conditions, we * want to have this debug stuff here just in case somethings not * working. Search the bitmap for the space we are trying to use to * make sure its actually there. If its not there then we need to stop * because something has gone wrong. */ search_start = *offset; search_bytes = *bytes; search_bytes = min(search_bytes, end - search_start + 1); ret = search_bitmap(ctl, bitmap_info, search_start, search_bytes); ===BUG_ON(ret 0 || search_start != *offset); So question is now: how do I recover from this? :-) -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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: Btrfs bug with g38867a2 and a question
On Thu, Sep 22, 2011 at 01:05:28PM +0200, David Sterba wrote: On Thu, Sep 22, 2011 at 12:13:44PM +0200, Mathieu Chouquet-Stringer wrote: On Thu, Sep 22, 2011 at 01:10:55AM +0200, David Sterba wrote: please prefix printk messages with btrfs: Well my computer crashed before I could reboot with the newly compiled kernel. And now it bugs while it tries to mount the kernel meaning my computer is fscked! :-) Bug at fs/btrfs/free-space-cache.c:1327 (I have a screenshot if needed) Yes please. There you go: http://mathieu.csetco.com/btrfs-crash3.jpg -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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: Btrfs bug with g38867a2 and a question
On Thu, Sep 22, 2011 at 10:12:12AM -0400, Josef Bacik wrote:
Well that is from the tree logging code, so give this a whirl. It's
going to dump a lot of info so make sure you capture everything before
the --- cut here --- line. Thanks,
The patch doesn't apply cleanly to the latest git (since my laptop
doesn't boot anymore, I'm using a different host to compile this) but it
was simple enough to patch manually. Right now I'm on v3.1-rc7-d93dc5c.
I'm compiling at the moment, so bear with me! :-)
My patch looks like this:
--- fs/btrfs/free-space-cache.c.orig2011-09-22 11:51:46.442129324 +0200
+++ fs/btrfs/free-space-cache.c 2011-09-22 17:11:46.715162968 +0200
@@ -381,6 +381,8 @@ int __load_free_space_cache(struct btrfs
}
if (entry-type == BTRFS_FREE_SPACE_EXTENT) {
+ printk(KERN_ERR adding extent [%llu-%llu]\n,
+ e-offset, e-bytes);
spin_lock(ctl-tree_lock);
ret = link_free_space(ctl, e);
spin_unlock(ctl-tree_lock);
@@ -402,6 +404,8 @@ int __load_free_space_cache(struct btrfs
page_cache_release(page);
goto free_cache;
}
+ printk(KERN_ERR adding bitmap [%llu-%llu]\n,
+ e-offset, e-bytes);
spin_lock(ctl-tree_lock);
ret = link_free_space(ctl, e);
ctl-total_bitmaps++;
--
Mathieu Chouquet-Stringer math...@csetco.com
The sun itself sees not till heaven clears.
-- William Shakespeare --
--
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: Btrfs bug with g38867a2 and a question
On Thu, Sep 22, 2011 at 10:12:12AM -0400, Josef Bacik wrote: Well that is from the tree logging code, so give this a whirl. It's going to dump a lot of info so make sure you capture everything before the --- cut here --- line. Thanks, Here's the output of this patch: http://mathieu.csetco.com/btrfs/IMG_20110922_200713.jpg http://mathieu.csetco.com/btrfs/IMG_20110922_200817.jpg http://mathieu.csetco.com/btrfs/IMG_20110922_200829.jpg http://mathieu.csetco.com/btrfs/IMG_20110922_200841.jpg http://mathieu.csetco.com/btrfs/IMG_20110922_200849.jpg http://mathieu.csetco.com/btrfs/IMG_20110922_200900.jpg http://mathieu.csetco.com/btrfs/IMG_20110922_200909.jpg http://mathieu.csetco.com/btrfs/IMG_20110922_200922.jpg -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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: Btrfs bug with g38867a2 and a question
On Thu, Sep 22, 2011 at 03:00:03PM -0400, Josef Bacik wrote: Oh wow sorry I sent you the completely wrong patch, I wish I had caught your reply earlier. Can you run with this patch, which is the one I meant to give you :). Thanks, No worries, I've applied your patch (seems your thunderbird mangled line returns) and I'm rebooting... -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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: Btrfs bug with g38867a2 and a question
On Thu, Sep 22, 2011 at 09:30:07PM +0200, Mathieu Chouquet-Stringer wrote: On Thu, Sep 22, 2011 at 03:00:03PM -0400, Josef Bacik wrote: Oh wow sorry I sent you the completely wrong patch, I wish I had caught your reply earlier. Can you run with this patch, which is the one I meant to give you :). Thanks, No worries, I've applied your patch (seems your thunderbird mangled line returns) and I'm rebooting... There: http://mathieu.csetco.com/btrfs/btrfs-screenshots.tar -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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
Btrfs bug with g38867a2 and a question
Hello all, I've been using BTRFS for quite some time on this laptop and I just recompiled the latest kernel from git (3.1.0-rc6-00247-g38867a2). After a couple minutes, I hit this bug twice (this a hand written transcript, pics here [1]) kernel BUG at fs/btrfs/inode.c:785! stack being: _raw_spin_unlock_irqrestore __wake_up btrfs_tree_read_unlock_blocking free_extent_buffer run_delalloc_nocow run_dellaloc_range free_extent_state find_lock_delalloc_range.constrpop __extent_writepage ... Note the stack trace is exactly the same in these two crashes. Since google found nothing, I'm asking for your help! Looking at the source, line 785 is function cow_file_range, code: BUG_ON(btrfs_is_free_space_inode(root, inode)); My fs (a simple partition on a OCZ-VERTEX2 ssd) is mounted with the following options: ssd,discard,autodefrag with disk space caching as it had been added earlier: btrfs: disk space caching is enabled Btrfs detected SSD devices, enabling SSD mode Anything I could do to help debug this one? Moreover, I've been experiencing long lags when my computer seems to be just busy doing writes (right now I'm on 3.1.0-rc6-00067-gf1fcd9f): it's not hung or anything except all IOs are blocked (hence I can start anything to see what's going on but I have a gauge on my xfce panel that goes 100% with writes). After some point, it just recovers and everything is back to normal. I've tried capturing something with sysrq-t but I haven't been able to find anything striking. Should I just submit something similar to this mailing list? [1] http://mathieu.csetco.com/btrfs-crash1.jpg http://mathieu.csetco.com/btrfs-crash2.jpg -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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: Btrfs bug with g38867a2 and a question
On Wed, Sep 21, 2011 at 04:18:29PM -0400, Josef Bacik wrote: Yup, can you apply this patch and reproduce? It will print out some debug info before the --- cut here --- line, which is what I need. Thanks, Compiling right now. That said, I had the same exact trace under rc6-00067-gf1fcd9f (right after rebooting to this older kernel) so it doesn't seem to be related to the latest git... Not sure how to trigger the bug though, I'll keep you posted! -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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: Poor read performance on high-end server
Hello, freek.dijks...@sara.nl (Freek Dijkstra) writes: [...] Here are the exact settings: ~# mkfs.btrfs -d raid0 /dev/sdd /dev/sde /dev/sdf /dev/sdg \ /dev/sdh /dev/sdi /dev/sdj /dev/sdk /dev/sdl /dev/sdm \ /dev/sdn /dev/sdo /dev/sdp /dev/sdq /dev/sdr /dev/sds nodesize 4096 leafsize 4096 sectorsize 4096 size 2.33TB Btrfs Btrfs v0.19 Don't you need to stripe metadata too (with -m raid0)? Or you may be limited by your metadata drive? -- Mathieu Chouquet-Stringer mchou...@free.fr The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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: Free space left
Hello, kreij...@gmail.com (Goffredo Baroncelli) writes: Try btrfs-show [...] How do you read this then: Label: none uuid: 27fafa43-7ad0-4e8a-ada8-36f73ef8984c Total devices 2 FS bytes used 79.63GB devid2 size 111.79GB used 111.01GB path /dev/sdb devid1 size 111.79GB used 111.03GB path /dev/sda I'm pretty sure I created this fs with -d raid1 -m raid1! Speaking of which, is there a way to read a FS configuration: how can I tell this FS really uses raid1 for both data and metadata? The used column is surprising: if it's a mirror why 111.01 and 111.03? And why all the space is being used anyway: I mean what's the difference between the 79.63GB and 111.0[13]? And the output of df is confusing too: /dev/sdb 234441648 83501968 150939680 36% /space It's reporting twice the total space but I think I remember looking it up and that should be fixed in a future kernel version. -- Mathieu Chouquet-Stringer mchou...@free.fr The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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
