All free space eaten during defragmenting (3.14)
Dear list, A tried to make a full defragmenting on my $HOME directory (which doesn't contain any snapshots). After some hours of running, it stopped with „No space left on device” error. I checked and it ate about 50 GB of free space. Before: Data, single: total=433.83GiB, used=~380.00GiB After: Data, single: total=433.83GiB, used=~430.00GiB Both times: Metadata, DUP: total=8.00GiB, used=7.08GiB In the btrfs fi df man page I didn't find anything that is related to this phenomenon. My questions are: - Is it a bug or some consequence of the defrag process? - Can I reclaim somehow the free space? Command used: shopt -s dotglob for i in *; do echo $i; btrfs fi defrag -clzo -r $i; done Btrfs and kernel version: Btrfs v3.12+20131125 Linux 3.14.4-1.gbebeb6f-desktop #1 SMP PREEMPT x86_64 Best regards, Ákos -- 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
Instant reboot while defragging on 3.13-rc5
Dear list members, I upgraded to 3.13-rc5 kernel and started to defrag my whole file system with the following commands: cd / for i in */*; do if [[ $i != windows* ]]; then echo --$i--; btrfs fi defrag -clzo -r $i; fi; done 21 | tee /root/defrag After 10 or 15 seconds my computer reboots itself without any warning. In dmesg I see only the following: [ 531.866566] btrfs: device fsid 2cc2b266-3f04-4f1c-8477-cf7efd6ac139 devid 1 transid 396679 /dev/sda7 [ 532.001919] watchdog watchdog0: watchdog did not stop! [ 532.002719] watchdog watchdog0: watchdog did not stop! Together with this I'm constantly getting sysfs WARNINGS into dmesg, but I don't think this would be related: WARNING: CPU: 5 PID: 1644 at /home/abuild/rpmbuild/BUILD/kernel- desktop-3.13.rc5/linux-3.13-rc5/fs/sysfs/group.c:214 device_del+0x3b/0x1b0() sysfs group 81c7e040 not found for kobject 'hidraw2' Versions: OS: openSUSE 13.1 Kernel: 3.13.0-rc5-1.g7127d5f-desktop btrfs: v3.12+20131125 Ákos -- 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-ino-cache runs on every boot for 6 minutes
Liu Bo a következőt írta ekkor: 2013. december 6. 21:30:34 It seems that we should owe credit to the updated 3.13 kernel, could you please try again 3.13 kernel without the patch? thanks, -liubo I forcibly reinstalled the 3.13 kernel from the repository, booted from it twice and yes, it really seems that this bug is fixed now. Thank you for your time. Ákos -- 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-ino-cache runs on every boot for 6 minutes
A következőt írtad ekkor: 2013. december 6. 14:04:19 Could you please try the following and show me the output of dmesg? thanks, -liubo The following happened: - I upgraded to 3.13.0-rc2-6.ge7c00d8 (since the original 3.12 kernel with SUSE patches is not available anymore) - Patched it and booted from that, compiled the NVIDIA driver - and suddenly everything started to work fine. Now I don't have to wait 6 minutes for the [btrfs-ino-cache] process. One thing I noticed: before any logging would start, kernel prints out some (initramfs?) messages, like: Waiting for device /dev/disk/... to appear [...] fsck succeeded Mounting root read-write Mounting root /dev/disk/... mount -o rw,compress=lzo,space_cache,noatime,inode_cache /dev/... /root And logging starts from this point. The interesting point is the initramfs mounting options: with the stock 3.12 kernel I had only the following: rw,compress=lzo,space_cache. But now it's rw,compress=lzo,space_cache,noatime,inode_cache. In /etc/fstab the options are intact for a month now. Maybe I should have regenerated the initrd when I added the fstab mount options noatime and inode_cache? I searched for your extra kernel messages in dmesg, but I didn't find them, although here is the dmesg output: http://paste.opensuse.org/30797527 Thank you, Ákos -- 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-ino-cache runs on every boot for 6 minutes
Dear Duncan, Thank you for your advices! Unfortunately I haven't found a good documentation on when I should use a cache_, that's why I thought it's all the same, won't hurt :). Now, if this bug is fixed, I'll turn off the inode_cache, if it's unnecessary. About autodefrag: yes, I'm considering running a total defragmentation on my whole drive (/), but unfortunately there is a bug which prevented me from doing it: it's a defrag panic which was fixed in 3.13. So either I wait until that kernel is out or I start a rebalance. The latter seems better now :). Thank you. Ákos Ps.: sorry for not replying to your letter in the thread but that didn't arrive in my mailbox. -- 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-ino-cache runs on every boot for 6 minutes
Thank you for your answer. Here are the blocked states logs. Since I had a plenty of time, I made multiple of them. The last two are the longest of them. - http://paste.opensuse.org/view/raw/51654551 - http://paste.opensuse.org/view/raw/39005796 - http://paste.opensuse.org/view/raw/38028651 - http://paste.opensuse.org/view/raw/21592065 - http://paste.opensuse.org/view/raw/46655344 - http://paste.opensuse.org/view/raw/26821272 Ákos -- 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-ino-cache runs on every boot for 6 minutes
Dear list members, I'm not sure if this a bug or an intended behaviour, since I've yet to find a reliable source with Google search. My problem is the following: with the 3.12 kernel on every single boot (even when the computer was shut down clear) the process [btrfs-ino-cache] is preventing the successful startup of X because it's running for 6 minutes. I can see this in iotop and while that program runs the whole system is being blocked. After 6 minutes I restart X and everyting goes normal from that point on. My question is: is that necessary to regenerate the inode cache on every boot or is this a bug? Of course if I remove the inode_cache option from fstab, this phenomenon disappears. Versions: - OS: openSUSE 13.1 - Kernel: 3.12.0-6.ge7c00d8-desktop #1 SMP PREEMPT Tue Nov 12 13:09:24 UTC 2013 (e7c00d8) - Mount options: compress=lzo,space_cache,inode_cache,noatime Best regards, Ákos -- 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 assertion failed: !memcmp_extent_buffer() and bug at ctree.h:3832
Dear list members, After a quick directory defragging, I tried to start the mysql daemon. Then suddenly to following appeared in the kernel log and the whole system hung up. This log is also from an instant copy over SSH. Now I'm planning to run a btrfsck on the file system, also. [ 4878.255759] BTRFS assertion failed: !memcmp_extent_buffer(b, disk_key, offsetof(struct btrfs_leaf, items[0].key), sizeof(disk_key)), file: /home/abuild/rpmbuild/BUILD/kernel-desktop-3.12.0/linux-3.12/fs/btrfs/ctree.c, line: 2444 [ 4878.255788] [ cut here ] [ 4878.255791] kernel BUG at /home/abuild/rpmbuild/BUILD/kernel- desktop-3.12.0/linux-3.12/fs/btrfs/ctree.h:3832! [ 4878.255792] invalid opcode: [#1] PREEMPT SMP [ 4878.255795] Modules linked in: bnep bluetooth rfkill xt_tcpudp xt_pkttype xt_LOG xt_limit af_packet ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack ip6table_filter ip6_tables fuse snd_hda_codec_hdmi snd_hda_codec_realtek nvidia(PO) snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq snd_timer snd_seq_device snd gpio_ich coretemp kvm_intel iTCO_wdt r8169 iTCO_vendor_support soundcore snd_page_alloc mxm_wmi usb_storage sr_mod mii serio_raw kvm drm pcspkr lpc_ich mfd_core cdrom i7core_edac wmi edac_core i2c_i801 shpchp button acpi_cpufreq sg nf_conntrack ip_tables x_tables dm_mod autofs4 btrfs raid6_pq xor libcrc32c crc32c_intel hid_logitech_dj [ 4878.255829] processor thermal_sys scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_dh ata_generic ata_piix [ 4878.255836] CPU: 1 PID: 23068 Comm: btrfs-endio-wri Tainted: P O 3.12.0-6.ge7c00d8-desktop #1 [ 4878.255838] Hardware name: MSI MS-7522/MSI X58 Pro-E (MS-7522), BIOS V8.15 03/19/2011 [ 4878.255840] task: 8801ce70e580 ti: 88005e776000 task.ti: 88005e776000 [ 4878.255841] RIP: 0010:[a0133525] [a0133525] assfail.constprop.38+0x1a/0x1c [btrfs] [ 4878.255860] RSP: 0018:88005e7779b8 EFLAGS: 00010286 [ 4878.255862] RAX: 00d9 RBX: 8801daba5d00 RCX: 7c72 [ 4878.255863] RDX: 7c72 RSI: 0046 RDI: 0246 [ 4878.255865] RBP: 880192529960 R08: 000a R09: 15f7 [ 4878.255866] R10: R11: 88005e86 R12: [ 4878.255867] R13: 1600 R14: R15: [ 4878.255869] FS: () GS:8802bfc2() knlGS: [ 4878.255871] CS: 0010 DS: ES: CR0: 8005003b [ 4878.255872] CR2: 007a385c CR3: 0001dc534000 CR4: 07e0 [ 4878.255874] Stack: [ 4878.255875] a00a003b 19ff8801daba5d00 6c000442 [ 4878.255878] a00a79da 8801c9121928 880065f21000 000550a3 [ 4878.255881] 8801722e2420 37306000 8801722e2420 8800 [ 4878.255884] Call Trace: [ 4878.255905] [a00a003b] key_search_validate+0x6b/0x70 [btrfs] [ 4878.255924] [a00a79da] btrfs_search_old_slot+0x2fa/0xa70 [btrfs] [ 4878.255954] [a0121a23] __resolve_indirect_refs+0x103/0x600 [btrfs] [ 4878.256069] [a012282a] find_parent_nodes+0x5da/0xe70 [btrfs] [ 4878.256178] [a0123a96] iterate_extent_inodes+0xf6/0x320 [btrfs] [ 4878.256291] [a0123d44] iterate_inodes_from_logical+0x84/0xa0 [btrfs] [ 4878.256400] [a00cb20b] record_extent_backrefs+0x6b/0xe0 [btrfs] [ 4878.256451] [a00d55b0] btrfs_finish_ordered_io+0x1d0/0xad0 [btrfs] [ 4878.256507] [a00f73d9] worker_loop+0x149/0x550 [btrfs] [ 4878.256581] [8107355f] kthread+0xaf/0xc0 [ 4878.256587] [815caf8c] ret_from_fork+0x7c/0xb0 [ 4878.256590] Code: c7 80 f9 13 a0 31 c0 e9 0e 52 48 e1 c3 0f 0b 0f 0b 89 f1 48 c7 c2 58 ff 13 a0 48 89 fe 31 c0 48 c7 c7 f8 ff 13 a0 e8 ef 51 48 e1 0f 0b 0f 0b 41 54 49 89 f4 55 48 89 d5 53 48 89 fb 48 83 ec 18 [ 4878.256615] RIP [a0133525] assfail.constprop.38+0x1a/0x1c [btrfs] [ 4878.256626] RSP 88005e7779b8 [ 4878.256642] ---[ end trace 2108d6eb38da44b5 ]--- [ 4878.256644] note: btrfs-endio-wri[23068] exited with preempt_count 1 Versions: - OS: openSUSE 13.1 - Kernel: Linux linux-suse 3.12.0-6.ge7c00d8-desktop #1 SMP PREEMPT Tue Nov 12 13:09:24 UTC 2013 (e7c00d8) x86_64 x86_64 x86_64 GNU/Linux Ákos -- 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
Kernel panic at (among others): free-space-cache.c:1179
Dear list members, When the kernel had paniced because of the key_search_validate() defrag bug, on the next restart it started to recreate its space- and inode caches. Both were finished in 5 minutes but when I tried to enter back to init 3, the kernel paniced and hung up again. Versions: - OS: openSUSE 13.1 - Kernel: Linux linux-suse.hu 3.12.0-6.ge7c00d8-desktop #1 SMP PREEMPT Tue Nov 12 13:09:24 UTC 2013 (e7c00d8) x86_64 x86_64 x86_64 GNU/Linux - Mount parameters: compress=lzo,space_cache,inode_cache,noatime Details (look at the timestamps, also): [ 118.916686] BTRFS error (device sda7): block group 191155404800 has wrong amount of free space [ 118.916689] BTRFS error (device sda7): failed to load free space cache for block group 191155404800 [ 119.918977] r8169 :06:00.0 eth0: link up [ 119.918985] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 125.812329] BTRFS error (device sda7): block group 216925208576 has wrong amount of free space [ 125.812334] BTRFS error (device sda7): failed to load free space cache for block group 216925208576 [ 151.923717] nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead. [ 158.606316] BTRFS error (device sda7): block group 189007921152 has wrong amount of free space [ 158.606321] BTRFS error (device sda7): failed to load free space cache for block group 189007921152 [ 256.812050] BTRFS error (device sda7): block group 157869408256 has wrong amount of free space [ 256.812054] BTRFS error (device sda7): failed to load free space cache for block group 157869408256 [ 436.042090] systemd-journald[350]: Received request to flush runtime journal from PID 1 [ 436.046824] [ cut here ] [ 436.046857] WARNING: CPU: 5 PID: 5297 at /home/abuild/rpmbuild/BUILD/kernel-desktop-3.12.0/linux-3.12/fs/btrfs/free- space-cache.c:1179 tree_insert_offset+0xbc/0xd0 [btrfs]() [ 436.046859] Modules linked in: xt_tcpudp xt_pkttype xt_LOG xt_limit af_packet ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack ip6table_filter ip6_tables fuse nvidia(PO) snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm iTCO_wdt snd_seq gpio_ich iTCO_vendor_support lpc_ich snd_timer snd_seq_device coretemp mxm_wmi sr_mod usb_storage kvm_intel kvm pcspkr serio_raw snd mfd_core cdrom i2c_i801 r8169 mii drm soundcore i7core_edac acpi_cpufreq edac_core snd_page_alloc wmi shpchp button sg nf_conntrack ip_tables x_tables dm_mod autofs4 btrfs raid6_pq xor libcrc32c crc32c_intel hid_logitech_dj processor thermal_sys [ 436.046886] scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_dh ata_generic ata_piix [ 436.046892] CPU: 5 PID: 5297 Comm: plymouthd Tainted: P O 3.12.0-6.ge7c00d8-desktop #1 [ 436.046894] Hardware name: MSI MS-7522/MSI X58 Pro-E (MS-7522), BIOS V8.15 03/19/2011 [ 436.046896] 0009 815bd494 810521d2 [ 436.046899] 8802926be2a0 8802aada9540 8802926be2a0 8800371ac150 [ 436.046902] 8000 a01d000c a01d0519 0582 [ 436.046905] Call Trace: [ 436.046918] [81004a28] dump_trace+0x88/0x310 [ 436.046927] [81004d80] show_stack_log_lvl+0xd0/0x1d0 [ 436.046934] [810061cc] show_stack+0x1c/0x50 [ 436.046941] [815bd494] dump_stack+0x50/0x89 [ 436.046951] [810521d2] warn_slowpath_common+0x72/0x90 [ 436.046977] [a01d000c] tree_insert_offset+0xbc/0xd0 [btrfs] [ 436.047132] [a01d0519] link_free_space+0x29/0x60 [btrfs] [ 436.047229] [a01d21bb] __btrfs_add_free_space+0x1db/0x430 [btrfs] [ 436.047356] [a019d079] btrfs_evict_inode+0x339/0x370 [btrfs] [ 436.047406] [811a5f57] evict+0xa7/0x1a0 [ 436.047414] [8119c45b] do_unlinkat+0x19b/0x250 [ 436.047423] [815cb03d] system_call_fastpath+0x1a/0x1f [ 436.047430] [7f64a66d81b7] 0x7f64a66d81b6 [ 436.047432] ---[ end trace c339ba3ff12c6258 ]--- [ 436.047434] btrfs: unable to add free space :-17 [ 436.047436] BTRFS assertion failed: ret != -EEXIST, file: /home/abuild/rpmbuild/BUILD/kernel-desktop-3.12.0/linux-3.12/fs/btrfs/free- space-cache.c, line: 1902 [ 436.047453] [ cut here ] [ 436.047646] kernel BUG at /home/abuild/rpmbuild/BUILD/kernel- desktop-3.12.0/linux-3.12/fs/btrfs/ctree.h:3832! [ 436.047843] invalid opcode: [#1] PREEMPT SMP [ 436.048113] Modules linked in: xt_tcpudp xt_pkttype xt_LOG xt_limit af_packet ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack ip6table_filter
btrfs warning on file system defrag
Dear list members, While I was defragging my file system, the following warning showed up in the dmesg: [ 6323.296521] [ cut here ] [ 6323.296551] WARNING: CPU: 5 PID: 13598 at /home/abuild/rpmbuild/BUILD/kernel- desktop-3.12.0/linux-3.12/fs/btrfs/backref.c:934 find_parent_nodes+0xe64/0xe70 [btrfs]() [ 6323.296552] Modules linked in: bnep bluetooth rfkill nvidia(PO) drm xt_tcpudp xt_pkttype xt_LOG xt_limit af_packet ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT ipt able_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack ip6table_filter ip6_tables fuse snd_hda_codec_hdmi coretemp gpio_ich mxm_wmi iTCO_wdt i TCO_vendor_support kvm_intel usb_storage kvm snd_hda_codec_realtek sr_mod pcspkr snd_hda_intel serio_raw snd_hda_codec cdrom r8169 mii acpi_cpufreq wmi snd_seq snd_hwdep snd_seq_device snd_pcm button snd_time r lpc_ich i7core_edac mfd_core i2c_i801 snd edac_core soundcore snd_page_alloc shpchp sg nf_conntrack ip_tables x_tables dm_mod autofs4 btrfs raid6_pq xor libcrc32c crc32c_intel hid_logitech_dj [ 6323.296580] processor thermal_sys scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_dh ata_generic ata_piix [last unloaded: drm] [ 6323.296588] CPU: 5 PID: 13598 Comm: btrfs-endio-wri Tainted: P O 3.12.0-6.ge7c00d8-desktop #1 [ 6323.296589] Hardware name: MSI MS-7522/MSI X58 Pro-E (MS-7522), BIOS V8.15 03/19/2011 [ 6323.296591] 0009 815bd494 810521d2 [ 6323.296594] 880109231ba8 88014d51d6e0 8800 [ 6323.296596] 88016d5a1640 a01100b4 0001 88010050 [ 6323.296598] Call Trace: [ 6323.296610] [81004a28] dump_trace+0x88/0x310 [ 6323.296613] [81004d80] show_stack_log_lvl+0xd0/0x1d0 [ 6323.296616] [810061cc] show_stack+0x1c/0x50 [ 6323.296621] [815bd494] dump_stack+0x50/0x89 [ 6323.296628] [810521d2] warn_slowpath_common+0x72/0x90 [ 6323.296643] [a01100b4] find_parent_nodes+0xe64/0xe70 [btrfs] [ 6323.296749] [a0110a96] iterate_extent_inodes+0xf6/0x320 [btrfs] [ 6323.296820] [a0110d44] iterate_inodes_from_logical+0x84/0xa0 [btrfs] [ 6323.296887] [a00b820b] record_extent_backrefs+0x6b/0xe0 [btrfs] [ 6323.296920] [a00c25b0] btrfs_finish_ordered_io+0x1d0/0xad0 [btrfs] [ 6323.297008] [a00e43d9] worker_loop+0x149/0x550 [btrfs] [ 6323.297065] [8107355f] kthread+0xaf/0xc0 [ 6323.297071] [815caf8c] ret_from_fork+0x7c/0xb0 [ 6323.297074] ---[ end trace f4f4fc91916d37a0 ]--- Versions: - OS: openSUSE 13.1 - Kernel: Linux linux-suse 3.12.0-6.ge7c00d8-desktop #1 SMP PREEMPT Tue Nov 12 13:09:24 UTC 2013 (e7c00d8) x86_64 x86_64 x86_64 GNU/Linux - btrfs: Btrfs v0.20-rc1 - Ran command: ./btrfs fi defrag -clzo -r -v /usr/ Ákos -- 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
systemd journalctl is 1.89sec on ext4, 1.49 min on btrfs
Dear list, I have two openSUSE 12.3 systems with kernel 3.9. On one of them there's an ext4 partition, while on the other there's a btrfs. I issued a time journalctl -b --no-pager command on both systems. This shows the logs from the current boot without passing them to less. On ext4 (3.9.3): real0m1.898s user0m0.291s sys 0m0.105s On btrfs (3.9.2): real1m49.698s user0m0.102s sys 0m0.470s Journalctl on btrfs was always this slow, some btrfsck were made on the file system too, but I don't think it was corrupted. On just the first run it's sluggish, after it's fast as the ext4 one. Is it a known issue or can I help somehow debugging this further? Best regards, Ákos Szőts -- 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
Kernel BUG at ctree.c:1144 and soft lockup while defragging
Dear list,
While I was trying to defrag a specified directory I got kernel BUGs and
warnings about CPUx stucked for twenty-some seconds.
The specified warnings were:
BUG at ctree.c:1144. Invalid opcode:
command: btrfs-endio-wri
Call trace top: btrfs_search_old_slot
The executed command in $HOME/.local:
find -xdev -type f -exec btrfs fi defrag -clzo '{}' \;
After that a soft lockup BUG occurred with systemd-journal with
btrfs_add_delayed_data_ref being on top of the call trace.
Since no log stayed in the journal, I took some pictures and uploaded them
here:
- Ctree bug: www.morrohun.hu/temp/btrfs/IMG_1983.JPG
www.morrohun.hu/temp/btrfs/IMG_1985.JPG
- Soft lockup with systemd-journal: www.morrohun.hu/temp/btrfs/IMG_1995.JPG
- Same stack trace without lockup and with btrfs-endio-wri:
www.morrohun.hu/temp/btrfs/IMG_1996.JPG
System: openSUSE 12.3, kernel 3.9.2-3.g97197ff-desktop.
If you need an image, can I take a snapshot just from the specified directory?
Best regards,
Ákos Szőts
--
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: systemd journalctl is 1.89sec on ext4, 1.49 min on btrfs
Thank you very much for you suggestions! I ran `filefrag` on /var/log/journal/ and the most fragmented files were: /var/log/journal/[...]/faa9e41c6.journal: 11136 extents found /var/log/journal/[...]/e9f8e1346c.journal: 633 extents found /var/log/journal/[...]/59ec50b631.journal: 3585 extents found /var/log/journal/[...]/59ec51d1b4.journal: 710 extents found /var/log/journal/[...]/f74afadee9.journal: 484 extents found Then I ran `btrfs fi defrag -v -f -clzo *` in the aforementioned directory three times and restarted the machine. Now, the `journalctl -b --no-pager` command runs in less than two seconds. I tried to further optimize my file system (MySQL big storage files are highly affected), but somewhere (for me it looks like, on random places) there are kernel errors, so I suspended the further defragmentation until those errors are tracked down. Thank you very much again. Ákos -- 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 on corrupted space cache under 3.7 and 3.8
I could successfully reproduce this issue while I was upgrading from 3.8 to 3.9. All the symptoms are exactly the same as I've written a month ago, nothing changed. I'll send you the link to the corrupted image file in a private mail. Btw, under Gentoo (SystemRescueCD to be precise) there are three warning in the btrfs-progs: http://pastebin.com/rYam2jWb Ákos -- 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
Kernel bug at extent-tree.c:5446
Dear list members, When I tried to recover my partition from the space cache bug (see http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg24360.html ), I issued the command `mount -o clear_cache -t btrfs /dev/sda7 /aaa/aaa`. After 10 minutes the mount command segfaulted. I cloned the latest btrfs-progs from Josef's Github account and ran the `btrfsck --repair` twice on the partition. Then I tried to mount under my normal openSUSE system (with kernel 3.9) and the following BUG appeared during the boot-up process: Kernel bug at extent-tree.c:5446 The picture I've taken: www.morrohun.hu/temp/btrfs/IMG_1770.JPG I tried to boot in an openSUSE Rescue CD, an Ubuntu Live CD, but just a SystemRescueCD was actually working, but I can't reach my partition. Even though I was able to make an image by `btrfs-image -c9 -t8` and I'll send you the link if it's requested. Best regards, Ákos Szőts -- 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 extent-tree.c:5446
Thank you for the fast response. I'll send the link to the image in a private mail. I filed a ticket here: https://bugzilla.kernel.org/show_bug.cgi?id=57631 Ákos 2013/5/6 Josef Bacik jba...@fusionio.com: I'd like to see the image and can you file a bug at bugzilla.kernel.org so I don't lose track of this issue? Make sure the component is set to Btrfs. Thanks, Josef -- 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 on mismatching generation_v2 in inode.c:835
What do you think; is this issue in the file system can be repaired with btrfsck? Or should I install a new, patched kernel on my partition somehow? -- 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 on mismatching generation_v2 in inode.c:835
Oh, that's a very good news! Thank you very much :) -- 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 on mismatching generation_v2 in inode.c:835
I ran two different versions of btrfsck on the partition. The first one was shipped with openSUSE 12.3, kernel 3.7. This is the original tool with which the partition was checked: http://paste.opensuse.org/74569620 The second one is from your tree (maybe it's newer): http://filebin.ca/bfbwJezYwCV/btrfsck-v2.txt Ákos -- 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 on mismatching generation_v2 in inode.c:835
I ran btrfsck three times and tried to restart the OS. After a generation_v2 resetting it booted and now it works! :) Thank you very much for your help! Two btrfsck run was needed for the complete cleanup, but interestingly the end statistics were a little bit different each time. Specifically, the values of - total fs tree bytes: 2285948928 - total extent tree bytes: 303124480 - btree space waste bytes: 742282214 lines varied with each run, even if there were no need of repairing. Ákos -- 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
Kernel BUG on corrupted space cache under 3.7 and 3.8
Dear list members, Yesterday I was about to restart my computer and that's why I closed every opened applications: three Eclipse instances, two other Java applications, 2 web browsers etc. It involved a lot of IO operations and before everything could settle down my system became unresponsive. I mean X co. worked fine, but anything related to IO (opening a new screen, a new application etc.) hung. My process explorer showed that nearly all of the applications which were shutting down have very high IO, but in fact there were no HDD head movement at all. I did a hard reset. Today morning when I restarted Linux I got a kernel BUG from btrfs. I successfully started a recovery Linux (with kernel 3.7) and when I tried to mount this partition, the bug/panic appeared again. After I could rebuild the space cache with clear_cache option and my system was fixed. Since all this logs are written only onto screen, I made some photographs :), and I uploaded them. System parameters: - openSUSE 12.3, Kernel 3.8, x86_64 - Linux linux-suse 3.8.0-5-desktop #1 SMP PREEMPT Tue Feb 26 20:55:05 UTC 2013 (db497a6) x86_64 x86_64 x86_64 GNU/Linux - Photos are made on Kernel 3.7 - Default mount options: compress=lzo,space_cache - On 3.7, the problematic line: fs/btrfs/free-space-cache.c:1553 - Photos location: www.morrohun.hu/temp/btrfs/[123].jpeg If you need any other information, ask me :). Best regards, Ákos Szőts -- 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 on corrupted space cache under 3.7 and 3.8
I fixed my file system here, so I can't provide more details now. Anyway, I cloned your repository and successfully compiled the tree (except for the mkfs program). But when I try to issue the command ./btrfs-image -c9 /dev/sda7 /home/linux/image.img I get the following: Could not open /dev/sda7 Open ctree failed I tried when it was unmounted and also when was mounted. An other thing happened in the meantime, but I write it to an other thread, because that's an other bug :). Ákos -- 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
Kernel bug on mismatching generation_v2 in inode.c:835
Dear list members, In my previous thread at http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg2.html there was a space_cache kernel bug/panic on kernel 3.8. I could successfully fix that with rebuilding the cache. But some files were missing/corrupted. So I booted a rescue CD with kernel 3.7 and ran btrfsck --repair, which repaired quite a few things. After a reboot I got the following message: [ 469.457386] btrfs: disk space caching is enabled [ 469.503612] btrfs: mismatching generation and generation_v2 found in root item. This root was probably mounted with an older kernel. Resetting all new fields. As soon as anything had wanted to read a bit from the file system, the hard drive went crazy and was working for 5-10 minutes. After I got a kernel panic which said there's an error in fs/btrfs/inode.c:835. In the moment I don't just mount, but want to read something from the mounted file system under the rescue system, the same procedure happens. I made some pictures of it (since I cannot read anything from the logs, if there are any). You can find them here: www.morrohun.hu/temp/btrfs/v2/[123].jpg I wanted to create an image with the aforementined btrfs-image tool, but yet to have any success . Could you please give me an advice what can I do now? Living on a live-CD is not a life insurance :) Best regards, Ákos Szőts -- 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 on mismatching generation_v2 in inode.c:835
The error was just a silly permission denied one. I uploaded the created image to www.morrohun.hu/temp/btrfs/btrfs.img SHA1: 90ee61e0724700495d26678d58dc229e04a04cc4 Please, write me when you downloaded and I'll delete it. I have the idea to run btrfsck from your tree on the file system again, but I won't touch the fs until you said so :). Ákos -- 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 on mismatching generation_v2 in inode.c:835
If my memory servers me well, it was taken in unmounted state. Do you want me to take an other one and compare the SHA1 values? -- 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
