Re: "Unable to find ref byte nr ...." (4.11 somehow fishy?)
8c79bbc4() knlGS: [11972.530621] CS: 0010 DS: ES: CR0: 80050033 [11972.530622] CR2: 7f908c811020 CR3: 8fe09000 CR4: 06a0 [11972.530622] Call Trace: [11972.530643] ? btrfs_merge_delayed_refs+0x63/0x540 [btrfs] [11972.530662] ? add_delayed_ref_head.isra.9+0x1d7/0x310 [btrfs] [11972.530677] __btrfs_run_delayed_refs+0x791/0x12b0 [btrfs] [11972.530694] btrfs_run_delayed_refs+0x6b/0x270 [btrfs] [11972.530708] ? walk_up_tree+0xed/0x210 [btrfs] [11972.530728] btrfs_should_end_transaction+0x55/0x60 [btrfs] [11972.530760] btrfs_drop_snapshot+0x3db/0x8c0 [btrfs] [11972.530781] btrfs_clean_one_deleted_snapshot+0xc1/0x110 [btrfs] [11972.530799] cleaner_kthread+0x14a/0x180 [btrfs] [11972.530803] kthread+0x125/0x140 [11972.530822] ? __btree_submit_bio_start+0x20/0x20 [btrfs] [11972.530823] ? kthread_park+0x60/0x60 [11972.530825] ret_from_fork+0x25/0x30 [11972.530826] Code: fe ff 48 8b 45 90 48 8b 40 60 f0 0f ba a8 18 ce 00 00 02 0f 92 c0 84 c0 41 59 75 11 44 89 f6 48 c7 c7 60 08 61 c0 e8 fc 02 c6 fb <0f> ff 48 8b 7d 90 b9 fe ff ff ff ba 24 1b 00 00 48 c7 c6 e0 a7 [11972.530854] ---[ end trace ed0da2429768f974 ]--- [11972.530858] BTRFS: error (device dm-1) in __btrfs_free_extent:6948: errno=-2 No such entry [11972.530860] BTRFS info (device dm-1): forced readonly [11972.530866] BTRFS: error (device dm-1) in btrfs_run_delayed_refs:2971: errno=-2 No such entry 2017-07-31 21:13 GMT+02:00 Ivan Sizov : > 2017-07-11 21:57 GMT+03:00 Clemens Eisserer : >> Hi, >> >> My external drive (single metadata, inline) caused an Ooops recently >> and went read-only. >> I wonder, has this something to do with the btrfs issues some have with 4.11? >> >> Best regards, Clemens >> >> [ 619.850316] perf: interrupt took too long (3958 > 3941), lowering >> kernel.perf_event_max_sample_rate to 5 >> [ 625.656835] [ cut here ] >> [ 625.656880] WARNING: CPU: 0 PID: 2919 at >> fs/btrfs/extent-tree.c:6936 __btrfs_free_extent.isra.61+0x7bf/0xe40 >> [btrfs] >> [ 625.656883] Modules linked in: uas usb_storage rfcomm ccm bnep >> sunrpc uvcvideo videobuf2_vmalloc videobuf2_memops btusb btrtl >> videobuf2_v4l2 btbcm btintel videobuf2_core bluetooth videodev media >> mei_wdt iTCO_wdt iTCO_vendor_support intel_powerclamp coretemp hp_wmi >> kvm_intel sparse_keymap ppdev snd_hda_codec_hdmi kvm arc4 >> snd_hda_codec_idt snd_hda_codec_generic iwldvm snd_hda_intel mac80211 >> snd_hda_codec irqbypass intel_cstate snd_hda_core intel_uncore iwlwifi >> snd_hwdep snd_seq snd_seq_device joydev intel_ips snd_pcm cfg80211 >> acpi_cpufreq tpm_infineon snd_timer snd rfkill lpc_ich soundcore >> shpchp mei_me mei wmi parport_pc parport hp_accel lis3lv02d >> input_polldev tpm_tis tpm_tis_core tpm binfmt_misc vboxpci(OE) >> vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) btrfs xor raid6_pq dm_crypt >> i915 mmc_block bcache >> [ 625.656931] crct10dif_pclmul crc32_pclmul crc32c_intel >> ghash_clmulni_intel i2c_algo_bit drm_kms_helper serio_raw sdhci_pci >> drm e1000e sdhci mmc_core ptp pps_core video >> [ 625.656943] CPU: 0 PID: 2919 Comm: btrfs-cleaner Tainted: G >> OE 4.11.8-200.fc25.x86_64 #1 >> [ 625.656944] Hardware name: Hewlett-Packard HP EliteBook 2540p/7008, >> BIOS 68CSU Ver. F.60 11/11/2015 >> [ 625.656945] Call Trace: >> [ 625.656952] dump_stack+0x63/0x86 >> [ 625.656955] __warn+0xcb/0xf0 >> [ 625.656956] warn_slowpath_null+0x1d/0x20 >> [ 625.656968] __btrfs_free_extent.isra.61+0x7bf/0xe40 [btrfs] >> [ 625.656977] ? btrfs_search_slot+0x429/0x9d0 [btrfs] >> [ 625.656992] ? btrfs_merge_delayed_refs+0x61/0x6c0 [btrfs] >> [ 625.657002] __btrfs_run_delayed_refs+0x501/0x12b0 [btrfs] >> [ 625.657017] ? btrfs_get_token_64+0x105/0x120 [btrfs] >> [ 625.657028] btrfs_run_delayed_refs+0x8f/0x2a0 [btrfs] >> [ 625.657042] ? free_extent_buffer+0x4b/0xa0 [btrfs] >> [ 625.657055] btrfs_should_end_transaction+0x48/0x60 [btrfs] >> [ 625.657066] btrfs_drop_snapshot+0x3e0/0x920 [btrfs] >> [ 625.657079] btrfs_clean_one_deleted_snapshot+0xbc/0x100 [btrfs] >> [ 625.657091] cleaner_kthread+0x133/0x180 [btrfs] >> [ 625.657093] kthread+0x109/0x140 >> [ 625.657105] ? __btree_submit_bio_start+0x20/0x20 [btrfs] >> [ 625.657106] ? kthread_park+0x90/0x90 >> [ 625.657110] ret_from_fork+0x2c/0x40 >> [ 625.657164] ---[ end trace 1c4d5dd9396052ae ]--- >> [ 625.657168] BTRFS info (device dm-1): leaf 183797051392 total ptrs >> 64 free space 186 >> [ 625.657172] item 0 key (178663501824 169 0) itemoff 3926 itemsize 69 >> [ 625.657173] extent refs 5 gen 1026 flags 258 >> [ 625.657174] shared block
"Unable to find ref byte nr ...." (4.11 somehow fishy?)
Hi, My external drive (single metadata, inline) caused an Ooops recently and went read-only. I wonder, has this something to do with the btrfs issues some have with 4.11? Best regards, Clemens [ 619.850316] perf: interrupt took too long (3958 > 3941), lowering kernel.perf_event_max_sample_rate to 5 [ 625.656835] [ cut here ] [ 625.656880] WARNING: CPU: 0 PID: 2919 at fs/btrfs/extent-tree.c:6936 __btrfs_free_extent.isra.61+0x7bf/0xe40 [btrfs] [ 625.656883] Modules linked in: uas usb_storage rfcomm ccm bnep sunrpc uvcvideo videobuf2_vmalloc videobuf2_memops btusb btrtl videobuf2_v4l2 btbcm btintel videobuf2_core bluetooth videodev media mei_wdt iTCO_wdt iTCO_vendor_support intel_powerclamp coretemp hp_wmi kvm_intel sparse_keymap ppdev snd_hda_codec_hdmi kvm arc4 snd_hda_codec_idt snd_hda_codec_generic iwldvm snd_hda_intel mac80211 snd_hda_codec irqbypass intel_cstate snd_hda_core intel_uncore iwlwifi snd_hwdep snd_seq snd_seq_device joydev intel_ips snd_pcm cfg80211 acpi_cpufreq tpm_infineon snd_timer snd rfkill lpc_ich soundcore shpchp mei_me mei wmi parport_pc parport hp_accel lis3lv02d input_polldev tpm_tis tpm_tis_core tpm binfmt_misc vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) btrfs xor raid6_pq dm_crypt i915 mmc_block bcache [ 625.656931] crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel i2c_algo_bit drm_kms_helper serio_raw sdhci_pci drm e1000e sdhci mmc_core ptp pps_core video [ 625.656943] CPU: 0 PID: 2919 Comm: btrfs-cleaner Tainted: G OE 4.11.8-200.fc25.x86_64 #1 [ 625.656944] Hardware name: Hewlett-Packard HP EliteBook 2540p/7008, BIOS 68CSU Ver. F.60 11/11/2015 [ 625.656945] Call Trace: [ 625.656952] dump_stack+0x63/0x86 [ 625.656955] __warn+0xcb/0xf0 [ 625.656956] warn_slowpath_null+0x1d/0x20 [ 625.656968] __btrfs_free_extent.isra.61+0x7bf/0xe40 [btrfs] [ 625.656977] ? btrfs_search_slot+0x429/0x9d0 [btrfs] [ 625.656992] ? btrfs_merge_delayed_refs+0x61/0x6c0 [btrfs] [ 625.657002] __btrfs_run_delayed_refs+0x501/0x12b0 [btrfs] [ 625.657017] ? btrfs_get_token_64+0x105/0x120 [btrfs] [ 625.657028] btrfs_run_delayed_refs+0x8f/0x2a0 [btrfs] [ 625.657042] ? free_extent_buffer+0x4b/0xa0 [btrfs] [ 625.657055] btrfs_should_end_transaction+0x48/0x60 [btrfs] [ 625.657066] btrfs_drop_snapshot+0x3e0/0x920 [btrfs] [ 625.657079] btrfs_clean_one_deleted_snapshot+0xbc/0x100 [btrfs] [ 625.657091] cleaner_kthread+0x133/0x180 [btrfs] [ 625.657093] kthread+0x109/0x140 [ 625.657105] ? __btree_submit_bio_start+0x20/0x20 [btrfs] [ 625.657106] ? kthread_park+0x90/0x90 [ 625.657110] ret_from_fork+0x2c/0x40 [ 625.657164] ---[ end trace 1c4d5dd9396052ae ]--- [ 625.657168] BTRFS info (device dm-1): leaf 183797051392 total ptrs 64 free space 186 [ 625.657172] item 0 key (178663501824 169 0) itemoff 3926 itemsize 69 [ 625.657173] extent refs 5 gen 1026 flags 258 [ 625.657174] shared block backref parent 245739773952 [ 625.657174] shared block backref parent 245673074688 [ 625.657174] shared block backref parent 181409894400 [ 625.657175] shared block backref parent 181343162368 [ 625.657175] shared block backref parent 180773711872 [ 625.657176] item 1 key (178663505920 168 4096) itemoff 3889 itemsize 37 [ 625.657177] extent refs 1 gen 1045 flags 1 [ 625.657177] shared data backref parent 179187650560 count 1 [ 625.657178] item 2 key (178663510016 168 4096) itemoff 3852 itemsize 37 [ 625.657179] extent refs 1 gen 1180 flags 1 [ 625.657180] shared data backref parent 245746434048 count 1 [ 625.657180] item 3 key (178663514112 169 0) itemoff 3819 itemsize 33 [ 625.657181] extent refs 1 gen 1098 flags 2 [ 625.657182] tree block backref root 2 [ 625.657183] item 4 key (178663518208 168 4096) itemoff 3769 itemsize 50 [ 625.657183] extent refs 2 gen 1030 flags 1 [ 625.657184] shared data backref parent 178675068928 count 1 [ 625.657184] shared data backref parent 178137387008 count 1 [ 625.657185] item 5 key (178663522304 168 4096) itemoff 3732 itemsize 37 [ 625.657186] extent refs 1 gen 1053 flags 1 [ 625.657186] shared data backref parent 180441329664 count 1 [ 625.657187] item 6 key (178663526400 169 0) itemoff 3555 itemsize 177 [ 625.657188] extent refs 17 gen 1196 flags 258 [ 625.657188] shared block backref parent 415361105920 [ 625.657189] shared block backref parent 415227764736 [ 625.657189] shared block backref parent 415125512192 [ 625.657190] shared block backref parent 414450216960 [ 625.657190] shared block backref parent 414116110336 [ 625.657190] shared block backref parent 414103474176 [ 625.657191] shared block backref parent 412705067008 [ 625.657191] shared block backref parent 412643041280 [ 625.657192] shared block backref parent 390315855872 [ 625.657192] shared block backref parent 287440842752 [ 625.657192] shared block backref parent 287294996480 [ 625.657193] shared block backref parent 266445434880 [ 625.657193] shared block backref parent 256855588864 [ 625.657194
Re: [PATCH v2 3/4] btrfs: Add zstd support
> So, I don't see any problem making the level configurable. +1 - configureable compression level would be very appreciated from my side. Can't wait until zstd support is mainline :) Thanks and br, Clemens -- 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 during backup to zlib-compressed btrfs-volume (kernel stack frame pointer at ffff9f1f433ebf50 in kworker/u8:7:6702 has bad value (null))
Hi, During a backup to an external USB3 hdd with the following mount options "rw,nosuid,nodev,relatime,compress-force=zlib,space_cache,subvolid=5,subvol=/,user" runnning linux-4.10.11-200.fc25.x86_64 I got the backtrace at the end of the email. Best regards, Clemens [ 3723.511132] WARNING: kernel stack frame pointer at 9f1f433ebf50 in kworker/u8:7:6702 has bad value (null) [ 3723.511133] unwind stack type:0 next_sp: (null) mask:2 graph_idx:0 [ 3723.511135] 9f1f433ebab8: 1000 (0x1000) [ 3723.511136] 9f1f433ebac0: 9f1f49184000 (0x9f1f49184000) [ 3723.511136] 9f1f433ebac8: 9f1f491849b0 (0x9f1f491849b0) [ 3723.511136] 9f1f433ebad0: ... [ 3723.511137] 9f1f433ebad8: 9f1f433ebb70 (0x9f1f433ebb70) [ 3723.511137] 9f1f433ebae0: 0009 (0x9) [ 3723.511138] 9f1f433ebae8: 0004 (0x4) [ 3723.511138] 9f1f433ebaf0: 000a (0xa) [ 3723.511138] 9f1f433ebaf8: ... [ 3723.511139] 9f1f433ebb00: 0060 (0x60) [ 3723.511139] 9f1f433ebb08: 0001 (0x1) [ 3723.511140] 9f1f433ebb10: 000a (0xa) [ 3723.511140] 9f1f433ebb18: 0107 (0x107) [ 3723.511141] 9f1f433ebb20: 9f1f491840bc (0x9f1f491840bc) [ 3723.511141] 9f1f433ebb28: 9f1f49184000 (0x9f1f49184000) [ 3723.511141] 9f1f433ebb30: ff10 (0xff10) [ 3723.511145] 9f1f433ebb38: 91430e4d (scan_tree+0xbd/0x110) [ 3723.511145] 9f1f433ebb40: 0010 (0x10) [ 3723.511146] 9f1f433ebb48: 0216 (0x216) [ 3723.511146] 9f1f433ebb50: 9f1f433ebb68 (0x9f1f433ebb68) [ 3723.511146] 9f1f433ebb58: 0018 (0x18) [ 3723.511147] 9f1f433ebb60: 9f1f49184000 (0x9f1f49184000) [ 3723.511147] 9f1f433ebb68: 9f1f491840bc (0x9f1f491840bc) [ 3723.511148] 9f1f433ebb70: 9f1f433ebbb0 (0x9f1f433ebbb0) [ 3723.511149] 9f1f433ebb78: 91432949 (zlib_tr_flush_block+0x79/0x760) [ 3723.511149] 9f1f433ebb80: 9f1f49193748 (0x9f1f49193748) [ 3723.511150] 9f1f433ebb88: 9f1f49184000 (0x9f1f49184000) [ 3723.511150] 9f1f433ebb90: 0003 (0x3) [ 3723.511151] 9f1f433ebb98: efef (0xefef) [ 3723.511151] 9f1f433ebba0: 0005 (0x5) [ 3723.511151] 9f1f433ebba8: 8c16076494e8 (0x8c16076494e8) [ 3723.511152] 9f1f433ebbb0: 9f1f433ebbd8 (0x9f1f433ebbd8) [ 3723.511153] 9f1f433ebbb8: 91430355 (deflate_fast+0x295/0x2e0) [ 3723.511153] 9f1f433ebbc0: 9f1f49184000 (0x9f1f49184000) [ 3723.511154] 9f1f433ebbc8: 8c1607649480 (0x8c1607649480) [ 3723.511154] 9f1f433ebbd0: 0003 (0x3) [ 3723.511155] 9f1f433ebbd8: 9f1f433ebc00 (0x9f1f433ebc00) [ 3723.511156] 9f1f433ebbe0: 914308fe (zlib_deflate+0xae/0x3a0) [ 3723.511156] 9f1f433ebbe8: d25e42de5340 (0xd25e42de5340) [ 3723.511157] 9f1f433ebbf0: 0002 (0x2) [ 3723.511157] 9f1f433ebbf8: 1000 (0x1000) [ 3723.511157] 9f1f433ebc00: 9f1f433ebc70 (0x9f1f433ebc70) [ 3723.511177] 9f1f433ebc08: c05b9198 (zlib_compress_pages+0x148/0x420 [btrfs]) [ 3723.511178] 9f1f433ebc10: 076494e8 (0x76494e8) [ 3723.511178] 9f1f433ebc18: 0020 (0x20) [ 3723.511179] 9f1f433ebc20: 8c1614774a88 (0x8c1614774a88) [ 3723.511179] 9f1f433ebc28: 8c144d973e00 (0x8c144d973e00) [ 3723.511180] 9f1f433ebc30: d25e41b89e40 (0xd25e41b89e40) [ 3723.511180] 9f1f433ebc38: 8c1607649480 (0x8c1607649480) [ 3723.511180] 9f1f433ebc40: 0004e000 (0x4e000) [ 3723.511181] 9f1f433ebc48: 0001 (0x1) [ 3723.511181] 9f1f433ebc50: 8c1614774a88 (0x8c1614774a88) [ 3723.511182] 9f1f433ebc58: 0004 (0x4) [ 3723.511182] 9f1f433ebc60: 0002 (0x2) [ 3723.511182] 9f1f433ebc68: 8c16076494e8 (0x8c16076494e8) [ 3723.511183] 9f1f433ebc70: 9f1f433ebcd8 (0x9f1f433ebcd8) [ 3723.511194] 9f1f433ebc78: c05bb5d8 (btrfs_compress_pages+0x78/0xa0 [btrfs]) [ 3723.511194] 9f1f433ebc80: 9f1f433ebd80 (0x9f1f433ebd80) [ 3723.511195] 9f1f433ebc88: 9f1f433ebd90 (0x9f1f433ebd90) [ 3723.511195] 9f1f433ebc90: 9f1f433ebd88 (0x9f1f433ebd88) [ 3723.511196] 9f1f433ebc98: 0002 (0x2) [ 3723.511196] 9f1f433ebca0: 8c144d973e00 (0x8c144d973e00) [ 3723.511196] 9f1f433ebca8: 0020 (0x20) [ 3723.511197] 9f1f433ebcb0: 0004 (0x4) [ 3723.511197] 9f1f433ebcb8: 0004 (0x4) [ 3723.511198] 9f1f433ebcc0: 8c144d973e00 (0x8c144d973e00) [ 3723.511198] 9f1f433ebcc8: 8c1614774910 (0x8c1614774910) [ 3723.511198] 9f1f433ebcd0: 0001 (0x1) [ 3723.511199] 9f1f433ebcd8: f
Will dupremove work for compressed btrfs volumnes?
Hi, Sorry if this is off-topic, but the dupremove project doesn't seem to have a mailing list - and it is actually only generating extent-same ioctls handled by btrfs anyway. I recently gave dupremove a try on my btrfs-volume (mounted with compress-force=lzo), specifically on a folder where I have a lot of proprietary stuff installed (so 15 copies of QT/java-runtime/webkit/...) and the result was: Kernel processed data (excludes target files): 11.9G Comparison of extent info shows a net change in shared extents of: 2.5M >From what I understand, only 2,5mb were successfully deduplicated. So I wonder, doesn't the extent-same ioctl work for compressed files, or does the dedupe-utility know about compression? Thank you in advance, Clemens -- 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 ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair
Hi Niccolo, > btrfs + dmcrypt + compress=lzo + autodefrag = corruption at first boot Just to be curious - couldn't it be a hardware issue? I use almost the same setup (compress-force=lzo instead of compress-force=lzo) on my laptop for 2-3 years and haven't experienced any issues since ~kernel-3.14 or so. Br, Clemens Eisserer 2016-05-07 17:45 GMT+02:00 Niccolò Belli : > btrfs + dmcrypt + compress=lzo + autodefrag = corruption at first boot > So discard is not the culprit. Will try to remove compress=lzo and > autodefrag and see if it still happens. > > [ 748.224346] BTRFS error (device dm-0): memmove bogus src_offset 5431 move > len 4294962894 len 16384 > [ 748.226206] [ cut here ] > [ 748.227831] kernel BUG at fs/btrfs/extent_io.c:5723! > [ 748.229498] invalid opcode: [#1] PREEMPT SMP > [ 748.231161] Modules linked in: ext4 mbcache jbd2 nls_iso8859_1 nls_cp437 > vfat fat snd_hda_codec_hdmi dell_laptop dcdbas dell_wmi iTCO_wdt > iTCO_vendor_support intel_rapl x86_pkg_temp_thermal intel_powerclamp > coretemp kvm_intel arc4 kvm irqbypass psmouse serio_raw pcspkr elan_i2c > snd_soc_ssm4567 snd_soc_rt286 snd_soc_rl6347a snd_soc_core i2c_hid iwlmvm > snd_compress snd_pcm_dmaengine ac97_bus mac80211 uvcvideo videobuf2_vmalloc > btusb videobuf2_memops cdc_ether btrtl usbnet iwlwifi btbcm videobuf2_v4l2 > btintel intel_pch_thermal videobuf2_core i2c_i801 videodev r8152 rtsx_pci_ms > cfg80211 bluetooth visor media mii memstick joydev evdev mousedev input_leds > rfkill mac_hid crc16 i915 fan thermal wmi dw_dmac int3403_thermal video > dw_dmac_core drm_kms_helper snd_soc_sst_acpi i2c_designware_platform > snd_soc_sst_match > [ 748.237203] snd_hda_intel 8250_dw i2c_designware_core gpio_lynxpoint > spi_pxa2xx_platform drm int3402_thermal snd_hda_codec battery tpm_crb > intel_hid snd_hda_core sparse_keymap fjes snd_hwdep int3400_thermal > acpi_thermal_rel tpm_tis snd_pcm intel_gtt tpm acpi_als syscopyarea > sysfillrect snd_timer sysimgblt fb_sys_fops mei_me i2c_algo_bit > processor_thermal_device kfifo_buf processor snd industrialio acpi_pad ac > int340x_thermal_zone mei intel_soc_dts_iosf button lpc_ich soundcore shpchp > sch_fq_codel ip_tables x_tables btrfs xor raid6_pq jitterentropy_rng > sha256_ssse3 sha256_generic hmac drbg ansi_cprng algif_skcipher af_alg uas > usb_storage dm_crypt dm_mod sd_mod rtsx_pci_sdmmc atkbd libps2 > crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel > aes_x86_64 lrw gf128mul glue_helper > [ 748.244176] ablk_helper cryptd ahci libahci libata scsi_mod xhci_pci > rtsx_pci xhci_hcd i8042 serio sdhci_acpi sdhci led_class mmc_core pl2303 > mos7720 usbserial parport hid_generic usbhid hid usbcore usb_common > [ 748.246662] CPU: 0 PID: 2316 Comm: pacman Not tainted 4.5.1-1-ARCH #1 > [ 748.249123] Hardware name: Dell Inc. XPS 13 9343/0F5KF3, BIOS A07 > 11/11/2015 > [ 748.251576] task: 8800d9d98e40 ti: 8800cec1 task.ti: > 8800cec1 > [ 748.254064] RIP: 0010:[] [] > memmove_extent_buffer+0x10c/0x110 [btrfs] > [ 748.256600] RSP: 0018:8800cec13c18 EFLAGS: 00010246 > [ 748.259120] RAX: RBX: 88020c01ba40 RCX: > 0056 > [ 748.261631] RDX: RSI: 88021e40db38 RDI: > 88021e40db38 > [ 748.264166] RBP: 8800cec13c48 R08: R09: > 033b > [ 748.266716] R10: R11: 033b R12: > eece > [ 748.269267] R13: 00010405 R14: 000104c9 R15: > 88020c01ba40 > [ 748.271818] FS: 7f14d4271740() GS:88021e40() > knlGS: > [ 748.274392] CS: 0010 DS: ES: CR0: 80050033 > [ 748.276987] CR2: 01630008 CR3: cffc8000 CR4: > 003406f0 > [ 748.279603] DR0: DR1: DR2: > > [ 748.282220] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 748.284815] Stack: > [ 748.287422] e3438cd2 88020c01ba40 00c4 > 002a > [ 748.290082] 006b 03a0 8800cec13ce8 > a02b612c > [ 748.292754] a02b433d 8800da9ca820 0028 > 8800daa78bd0 > [ 748.295441] Call Trace: > [ 748.298104] [] btrfs_del_items+0x33c/0x4a0 [btrfs] > [ 748.300827] [] ? btrfs_search_slot+0x90d/0x990 [btrfs] > [ 748.303564] [] ? btrfs_get_token_8+0x6c/0x130 [btrfs] > [ 748.306311] [] btrfs_truncate_inode_items+0x649/0xd20 > [btrfs] > [ 748.309071] [] ? > btrfs_delayed_inode_release_metadata.isra.1+0x4e/0xf0 [btrfs] > [ 748.311860] [] btrfs_evict_inode+0x485/0x5d0 [btrfs] > [ 748.314627] [] evict+0xc5/0x190 > [ 748.317412] [] iput+0x
Re: Bad performance with near-full FS
Hi, > Thanks for you reply, > If I really understand, it's always a good idea to keep more than 1% of > free space. Right ? Usually the rule of thumb is 10-20%. Br, Clemens -- 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: Deadlock with 3.15.10
Hi Liu, >> I've recently run into a deadlock on 3.15.10, don't know if the kernel >> stack-trace is useful: http://pastebin.com/guQNDAMX > > FYI, this's been fixed by https://patchwork.kernel.org/patch/4727711/ Thanks for letting me know. - Clemens -- 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
Deadlock with 3.15.10
Hi, I've recently run into a deadlock on 3.15.10, don't know if the kernel stack-trace is useful: http://pastebin.com/guQNDAMX Br, Clemens -- 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: ENOSPC on mostly empty file system
Hi Arnd, > Ok, one more data point: Why don't you provide the data point you were specifically asked for, "btrfs fi df" ;) Regards, Clemens -- 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: Large files, nodatacow and fragmentation
Hi Richard, > It is interesting that for me the number of extents before and after > bcache are essentially the same. > > The lesson here for me there is that the fragmentation of a btrfs > nodatacow file is not mitigated by bcache. There seems to be nothing I > can do to prevent that fragmentation, and may in fact be expected > behavior. This is to be expected - bcache behaves like a single, transparent block device - so for btrfs it doesn't matter whether you run on a "real" device or a bcache one. The performance increase is expected, however ;) Best regards, Clemens -- 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: Announcement: buttersink - like rsync for btrfs snapshots
Hi Jim, > To any core btrfs devs who are listening and care - the unreliability of > btrfs send/receive is IMO the single biggest roadblock to adoption of btrfs > as a serious next-gen FS. For you it are send/receive deficiencies, however there are many other feature/enhancement requests having top priority for other users. Fact is, just crying for improvements won't make things better - if you want a feature/enhancement done, you have several options: - Implement/fix it yourself - Go to your distribution provider with whom you have a support contract and make him implement what you would like to see - Sponsor somebody yourself to get it sone. > with (very) occasional filesystem corruption... IF I can rely on replication > to keep my data safe on another box. Without the replication, there's just > no reasonable case to be made to replace ZFS. ... and now the usual ZFS comparison to make devs jealous ;) Best regards, Clemens -- 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: ENOSPC with mkdir and rename
Hi Russel, > The Debian installer has BTRFS in a list of filesystems to choose with no > special notice about it. I'm thinking of filing a Debian bug requesting that > they put a warning against it. As long as it is not selected as the default filesystem, I think it is fine. Other distributions have been offering btrfs for some time now, too. Regards, Clemens -- 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: ENOSPC with mkdir and rename
Hi Hugo, >On the 3.15+ kernels, the block reserve is split out of metadata > and reported separately. This helps with the following process: Thanks a lot for pointing this out, I hadn't noticed this change until now. One thing I didn't find any information about is the overhead introduced by mixied-mode. It would be great if you could explain it in a few sentences. Thank you in advance, Clemens -- 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: ENOSPC with mkdir and rename
Hi Chris, > Hmm, it shouldn't be, the ENOSPC issues are well known and have been discussed > here for years. Which doesn't protect the *average* user from running into issues like this. Just because it has been discussed, doesn't mean nothing can/should be done about it ;) However, as I am only a user too and can't contribute in terms of code, I keep patient and observe how btrfs is evolving. One day or another, the ENOSPC issues will get fixed or worked arround, Regards, Clemens -- 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: ENOSPC with mkdir and rename
Hi Peter, > All of this is *very* surprising. I'm not new to BTRFS, I've been > using it on my own machines for multiple years. I didn't realise there > was an un-holstered footgun on my lap at this point. How can it be > made clear how to avoid the ENOSPC problem to myself and other > sysadmins? Or preferably not exist as a problem? I've also found the fixed metadata/data split to be an uncomfortable implementation detail, and some more flexible approach would be very welcome from my side. So far I've used BTRFS' mixed mode mentioned in the mkfs.btrfs man page: > -M|--mixedMix data and metadata chunks together for more efficient space > utilization. > This feature incurs a performance penalty in larger filesystems. > It is recommended for use with filesystems of 1 GiB or smaller. However I didn't find any information on how large the mentioned overhead is, or where it originates from. Best regards, Clemens -- 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
What do the "wait_current_trans" messages mean I see on my raspberry pi?
Hi, Over the weekend I tried to copy one external usb drive (on ext4) to another one formatted with btrfs. Now I came back, and 48h later only ~300GB were copied and I found messages like the following on syslog: May 16 18:33:13 raspberrypi kernel: [ 8161.213142] btrfs-endio-wri D c0420f24 0 3593 2 0x May 16 18:33:13 raspberrypi kernel: [ 8161.213735] [] (__schedule+0x288/0x568) from [] (wait_current_trans+0xcc/0x13c [btrfs]) May 16 18:33:13 raspberrypi kernel: [ 8161.214357] [] (wait_current_trans+0xcc/0x13c [btrfs]) from [] (start_transaction+0x2d8/0x43c [btrfs]) May 16 18:33:13 raspberrypi kernel: [ 8161.214956] [] (start_transaction+0x2d8/0x43c [btrfs]) from [] (btrfs_join_transaction+0x20/0x2c [btrfs]) May 16 18:33:13 raspberrypi kernel: [ 8161.215562] [] (btrfs_join_transaction+0x20/0x2c [btrfs]) from [] (btrfs_finish_ordered_io+0x2c4/0x5b0 [btrfs]) May 16 18:33:13 raspberrypi kernel: [ 8161.216233] [] (btrfs_finish_ordered_io+0x2c4/0x5b0 [btrfs]) from [] (worker_loop+0x150/0x674 [btrfs]) May 16 18:33:13 raspberrypi kernel: [ 8161.216631] [] (worker_loop+0x150/0x674 [btrfs]) from [] (kthread+0xa4/0xb0) May 16 18:33:13 raspberrypi kernel: [ 8161.218363] [] (kthread+0xa4/0xb0) from [] (ret_from_fork+0x14/0x3c) More of them are available at: http://pastebin.com/th9tuSas Any idea what they mean? Are they related to the slow speed I observed? Thank you in advance, Clemens -- 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: Rebalance makes BTRFS 10x slower
Hi Ducan, > But as I said, I'd sure like to get to the bottom of this one, since I do > believe it has other potential implications in terms of bugs, etc. In > theory, a balance should either not affect performance or should improve > it, so getting to the bottom of why it's having such a bad performance > impact for many really is something that needs to be done. I agree - getting to the bottom of this would be interesting. The question is how? Regards, Clemens -- 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: Rebalance makes BTRFS 10x slower
Hi, > I also found this to be the case as I rebalanced the root filesystem of my > Debian installation on this ThinkPad T520 on an Intel SSD 320. Same here, I ran balance on kernel-3.12 some time ago and after balancing performance dropped noticeable and stayed there. When booting natively I can see the HDD activity led lid for 10+ seconds (Samsung 830 SSD), working with the same system in virtualbox using direct device access is a real pain. Non of the measures I took (re-balance, fstrim, defraging all files on the volume, ...) had mentionable impact. Regards, Clemens -- 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: Is there any way to determine fragmentation for compressed btrfs volumes?
Hi again, So it seems performance issues caused by FS degredation are in the current development stage of btrfs not getting a lot of attention. Hopefully production use on facebook servers will expose one or another issue and with the developers being employed there chances are good btrfs will handle workload like mine more gracefully with these issues fixed. Thanks & best regards, Clemens 2014-04-08 21:41 GMT+02:00 Clemens Eisserer : > Hi Ducan, > >> You mention trying scrub and defragging the entire volume, but you don't >> mention balance. Balance by default rewrites all chunks (tho you can add >> filters to rewrite only say data chunks, not metadata, if you like), so >> that's what I'd say to try, as it should defrag in the process. >> >> Tho we've seen a few reports from people saying a full balance actually >> made for instance boot times longer instead of shorter, too. I haven't >> seen and don't have an explanation for that. > > Ah sorry, I confused scrub with balance. > I didn't do a scrub but actually I tried to balance the device as I > was told basically all data has to go through the allocator again > which most likely will improve on-disk layout. Unfourtunatly in my > case it made the situation a lot worse, when running this Linux system > in virtualbox (where disk access has a lot more overhead) it is now > even with the SSD super slow. > > >> Meanwhile, have you tried a trim/discard (fstrim command), and/or do you >> run with the discard (or is it trim) mount option? > I have tried with discard on and off - however this isn't a SSD issue. > > It is slow even for read-only workload, and windows on the same SSD > works as expected (with CrystalDiskMark showing the dirve meets the > specs (~350mb/s seq. write, 500b/s sequential read, good 4k random > values). > So I doubt this is an SSD issue. > > >> One more thing to consider. The btrfs of a year and a half ago was a >> rather less mature btrfs than we have today. I recently booted to backup >> here, and did a brand new mkfs.btrfs on my working filesystems to take >> advantage of several of the newer features > > I had hopes I could avoid that. > Having a FS in such a degraded state with the only option to re-create > it isn't that compelling ;) > > Thanks & regards, Clemens -- 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: Is there any way to determine fragmentation for compressed btrfs volumes?
Hi Ducan, > You mention trying scrub and defragging the entire volume, but you don't > mention balance. Balance by default rewrites all chunks (tho you can add > filters to rewrite only say data chunks, not metadata, if you like), so > that's what I'd say to try, as it should defrag in the process. > > Tho we've seen a few reports from people saying a full balance actually > made for instance boot times longer instead of shorter, too. I haven't > seen and don't have an explanation for that. Ah sorry, I confused scrub with balance. I didn't do a scrub but actually I tried to balance the device as I was told basically all data has to go through the allocator again which most likely will improve on-disk layout. Unfourtunatly in my case it made the situation a lot worse, when running this Linux system in virtualbox (where disk access has a lot more overhead) it is now even with the SSD super slow. > Meanwhile, have you tried a trim/discard (fstrim command), and/or do you > run with the discard (or is it trim) mount option? I have tried with discard on and off - however this isn't a SSD issue. It is slow even for read-only workload, and windows on the same SSD works as expected (with CrystalDiskMark showing the dirve meets the specs (~350mb/s seq. write, 500b/s sequential read, good 4k random values). So I doubt this is an SSD issue. > One more thing to consider. The btrfs of a year and a half ago was a > rather less mature btrfs than we have today. I recently booted to backup > here, and did a brand new mkfs.btrfs on my working filesystems to take > advantage of several of the newer features I had hopes I could avoid that. Having a FS in such a degraded state with the only option to re-create it isn't that compelling ;) Thanks & regards, Clemens -- 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 setup advice for laptop performance ?
Hi, > This is because every other filesystem (except ZFS) doesn't use COW > semantics. Nilfs2 also is COW based. Regards, Clemens -- 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
Is there any way to determine fragmentation for compressed btrfs volumes?
Hi, I've been running btrfs on my SSD powered laptop for about a year and a half (with force-compress=lzo and autodefrag) and it seems the volume has degraded quite a lot although I am not using snapshot functionality. No matter what I do (scrub, defrag ob the whole volume), files seem to stay highly fragmented - at least that is my guess. When e.g. starting up X11+XFCE the hdd led is lid for about 10s (the Samsung 830 can do up to 80k/iops random read), also starting google-chrome results in an active SSD for ~5s (although the chrome binary + libs is for sure < 200mb, so should be loaded in 500ms). What I wonder is how can I diagnose whats happening and why the FS is rather slow? The only target value I know is the extend count, which doesn't seem to be meaningful when using fragmentation. Thank you in advance, Clemens Eisserer -- 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: Filesystem extremly fragmented after scrub
Hi, > Some general notes .. VM images ... While NOCOW will prevent COW ... As mentioned the VM is configured to access the partition where linux is installed directly. So btrfs is not used as filesystem on the host machine, but rather on the guest which writes directly to disk (so no other filesystem is interfering here). > I'm not sure about fsck (presumably btrfsck), > but filefrag does not know about btrfs compression yet My bad, this was fsck from my ext2 boot partition ;) I wonder why my filesystem got so painfully slow after scrub. Is there any useful measure to determine how badly fragmented a btrfs volume is? Thanks and best regards, Clemens -- 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
Filesystem extremly fragmented after scrub
Hi, I am using btrfs on a single device with crompress-force=lzo and after I scrubbed the device once (kernel-3.12), the filesystem is extremly fragmented - running defrag on all file didn't improve the situation unfourtunately. Because I have a fast SSD this is barely noticeable when booting the system natively, however when working through VirtualBox (using direct disk access) where each access has far higher latency, the system responds really slow for file-system intensive tasks (VirtualBox "hdd-led" is constantly lid in this case). When booting fsck reports the filesystem is 26% non-continous. Is there anything I can try to get the FS into a healthier state? Thank you in advance, Clemens -- 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: How does btrfs handle bad blocks in raid1?
Hi George, > I really suspect a lot of bad block issues can be avoided by monitoring > SMART data. SMART is working very well for me with btrfs formatted drives. > SMART will detect when sectors silently fail and as those failures > accumulate, SMART will warn in an obvious way that the drive in question is > at end of life. So I think the whole bad block issue should ideally be > handled at a lower level than filesystem with modern hard drives. At least my original request was about cheap flash media, where you don't have the luxury that you can "trust" the hardware behaving properly. In fact, it might be benefitial for a SD card to not report ECC errors - most likely the user won't notice a small glitch playing back music - but he definitively will when the smartphone reports read errors and stopping playback which will cause that card to be RMAd. Also, wouldn't your argument be also valid for checksums - why checksum in software, when in theory the drive + controllers should do it anyway ;) Regards, Clemens -- 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
How does btrfs handle bad blocks in raid1?
Hi, I am running write-intensive (well sort of, one write every 10s) workloads on cheap flash media which proved to be horribly unreliable. A 32GB microSDHC card reported bad blocks after 4 days, while a usb pen drive returns bogus data without any warning at all. So I wonder, how would btrfs behave in raid1 on two such devices? Would it simply mark bad blocks as "bad" and continue to be operational, or will it bail out when some block can not be read/written anymore on one of the two devices? Thank you in advance, Clemens -- 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: rootfs crash
Hi Jogi, When I tried to recovered a broken btrfs-parition, I encountered the same errors you did - btrfs restore seems to be a bit broken. What helped was to: a. comment out the free()-calls which led to crashes b. re-run "btrfs restore" to account for the crashes which happen elsewhere, hopefully it will progress each run a little further as it did for me. Regards, Clemens -- 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: Btrfsck Assertion btrfs_find_last_root !(path->slots[0] == 0) - any hope left?
Hi again, After I found out about btrfs restore and btrfs-find-root, I gave it a try - unfortunately without success (full log at: http://pastebin.com/B2QUxhaj ): > parent transid verify failed on 27785830400 wanted 168295 found 168298 > parent transid verify failed on 27785830400 wanted 168295 found 168298 > Ignoring transid failure > Couldn't setup extent tree > Couldn't read fs root: -2 btrfs-find-root finds some blocks, but complains for each block about not matching generation - and restore refuses to mount that blocks. I would be really grateful for ideas how to get something back out of this broken FS ... Would it make sense to simply disable the transid checks? Thank you in advance, Clemens 2013/9/7 Clemens Eisserer : > Hi, > > Because of being clumsy, I recently overwrote my btrfs-partition. > Worse, the only recent backup I own is a dd-copy which was created > while the system was running. > > Both, btrfsck (from btrfsprogs-next) and mount -o recovery failed - so > I wonder, are there any steps left I could try? > > [root@localhost btrfs-progs]# ./btrfsck /dev/mapper/main > parent transid verify failed on 27785830400 wanted 168295 found 168298 > parent transid verify failed on 27785830400 wanted 168295 found 168298 > Ignoring transid failure > btrfsck: root-tree.c:46: btrfs_find_last_root: Assertion > `!(path->slots[0] == 0)' failed. > Aborted > > mount -o recovery: > [ 555.978120] device label fedora00 devid 1 transid 168295 /dev/mapper/ce > [ 555.981272] btrfs: enabling auto recovery > [ 555.981275] btrfs: disk space caching is enabled > [ 555.981276] btrfs: has skinny extents > [ 555.983736] parent transid verify failed on 27785830400 wanted > 168295 found 168298 > [ 555.983741] btrfs: failed to read tree root on dm-0 > [ 555.984014] parent transid verify failed on 27785830400 wanted > 168295 found 168298 > [ 555.984017] btrfs: failed to read tree root on dm-0 > [ 555.984487] parent transid verify failed on 27780313088 wanted > 168294 found 168297 > [ 555.984491] btrfs: failed to read tree root on dm-0 > [ 555.984951] parent transid verify failed on 27763916800 wanted > 168293 found 168299 > [ 555.984954] btrfs: failed to read tree root on dm-0 > [ 556.003065] btrfs bad tree block start 886699414819576 27357323264 > [ 556.003080] Failed to read block groups: -5 > [ 556.006211] btrfs: open_ctree failed > > Thank you in advance, Clemens -- 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
Btrfsck Assertion btrfs_find_last_root !(path->slots[0] == 0) - any hope left?
Hi, Because of being clumsy, I recently overwrote my btrfs-partition. Worse, the only recent backup I own is a dd-copy which was created while the system was running. Both, btrfsck (from btrfsprogs-next) and mount -o recovery failed - so I wonder, are there any steps left I could try? [root@localhost btrfs-progs]# ./btrfsck /dev/mapper/main parent transid verify failed on 27785830400 wanted 168295 found 168298 parent transid verify failed on 27785830400 wanted 168295 found 168298 Ignoring transid failure btrfsck: root-tree.c:46: btrfs_find_last_root: Assertion `!(path->slots[0] == 0)' failed. Aborted mount -o recovery: [ 555.978120] device label fedora00 devid 1 transid 168295 /dev/mapper/ce [ 555.981272] btrfs: enabling auto recovery [ 555.981275] btrfs: disk space caching is enabled [ 555.981276] btrfs: has skinny extents [ 555.983736] parent transid verify failed on 27785830400 wanted 168295 found 168298 [ 555.983741] btrfs: failed to read tree root on dm-0 [ 555.984014] parent transid verify failed on 27785830400 wanted 168295 found 168298 [ 555.984017] btrfs: failed to read tree root on dm-0 [ 555.984487] parent transid verify failed on 27780313088 wanted 168294 found 168297 [ 555.984491] btrfs: failed to read tree root on dm-0 [ 555.984951] parent transid verify failed on 27763916800 wanted 168293 found 168299 [ 555.984954] btrfs: failed to read tree root on dm-0 [ 556.003065] btrfs bad tree block start 886699414819576 27357323264 [ 556.003080] Failed to read block groups: -5 [ 556.006211] btrfs: open_ctree failed Thank you in advance, Clemens -- 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: snapshot space available
You are out of metadata, not "normal space". However, the good question is why 0.5GB of metadata are unused and btrfs reports no space left. I have seen similar behaviour on a machine of mine, with exactly 0.5GB of metadata unused. Regards 2013/8/26 Russell Coker : > Linux xev 3.10-2-amd64 #1 SMP Debian 3.10.5-1 (2013-08-07) x86_64 GNU/Linux > > I've attached a file of script output from a system running the above Debian > kernel on a system with an Intel 120G SSD. To get this working again I > extended the filesystem in question to also use a small USB flash device (4G > from memory) and then deleted some old snapshots to free some space. > > The most intereting part of the script output is pasted below. The system > reports that the filesystem is 82% full but that there is no space left. > > root@xev:~# df -h / > Filesystem Size Used Avail Use% > Mounted on > /dev/disk/by-uuid/586e6f48-2985-4115-9f89-f844b319c7c0 108G 87G 21G 82% > / > root@xev:~# btrfs filesystem df / > Data: total=101.57GB, used=81.50GB > System, DUP: total=8.00MB, used=20.00KB > System: total=4.00MB, used=0.00 > Metadata, DUP: total=3.00GB, used=2.50GB > Metadata: total=8.00MB, used=0.00 > root@xev:~# ls -l > test > bash: test: No space left on device > root@xev:~# touch test > touch: cannot touch ‘test’: No space left on device > root@xev:~# > > -- > My Main Blog http://etbe.coker.com.au/ > My Documents Bloghttp://doc.coker.com.au/ -- 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: Samba strict allocate = yes stops btrfs compression working
Hi, > The speed improvement for dumping large databases through samba with > strict allocate = yes to BTRFS was amazing. It reduced a 1 hour dump down > to 20 minutes. What you want btrfs to do is to allocate a file of fixed-size on disk in advance, without knowing how large the file will be after compression (which is the only thing of interest to btrfs). So the whole idea doesn't make a lot of sence. Sure, you could generate a 50gb file filled with zeros, but once you put real data in it, it will fragment a lot - probably even more than the file which was created without strict allocate. Regards -- 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: [PATCH RFC] Btrfs: track compression algorithm on inodes
I've been waiting for such functionality quite a long time, great to seem some progress here :) It would allow me to compress files which are not frequently accessed (~75%?) with zlib, while staying at LZO for everything else. > I think we should take the top-down approach and start with UI how to set > these attributes, Yes, some command-line tool to set the compression algorithm would be a better idea then using mountn.. Regards -- 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: Why does btrfs benchmark so badly in this case?
> What is going on here? Why is btrfs doing so poorly? Funny thing, I was thinking exactly the same when reading the article ;) Regards -- 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: abysmal rm performance?
> So... read up on the wiki a bit, then come back with questions you have > that aren't answered there. (I certainly had some I didn't see directly > answered there when I first started with btrfs.) I guess the original email was more ment as a bug-report than a question, as the question was more like a "can it really be that slow". The wiki most likely won't help explaining/solving the high metadata overhead either... Regards -- 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: unclean shutdown and space cache rebuild
Hi, > I suspect this is, at least in part, related to severe fragmentation > in /home. In his cause those issues are only present after an unclean shutdown - whereas fragmentation would show its effect after every reboot. Regards, Clemens -- 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: hang on 3.9, 3.10-rc5
Hi Jon, > Is this what you are looking for? > After this, the CPU gets "stuck" and I have to reboot. This issue has already been reported: https://bugzilla.kernel.org/show_bug.cgi?id=59451 Regards, Clemens -- 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
Two identical copies of an image mounted result in changes to both images if only one is modified
Hi, I've observed a rather strange behaviour while trying to mount two identical copies of the same image to different mount points. Each modification to one image is also performed in the second one. Example: dd if=/dev/sda? of=image1 bs=1M cp image1 image2 mount -o loop image1 m1 mount -o loop image2 m2 touch m2/hello ls -la m1 //will now also include a file calles "hello" Is this behaviour intentional and known or should I create a bug-report? I've deleted quite a bunch of files on my production system because of this... Thanks, Clemens -- 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: Btrfsck errors (fs tree 565 refs 125 not found) - how serious
Hi, >> You are running on an unmounted fs right? Also please make sure you are >> running >> the git version > > Yes, the fs was properly unmounted. > >> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git > > I still get those errors, I'll try to file a bug-report with the > tools/data required to reproduce this issue... Filed at: https://bugzilla.kernel.org/show_bug.cgi?id=59051 Regards -- 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: Btrfsck errors (fs tree 565 refs 125 not found) - how serious
Hi Josef, > You are running on an unmounted fs right? Also please make sure you are > running > the git version Yes, the fs was properly unmounted. > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git I still get those errors, I'll try to file a bug-report with the tools/data required to reproduce this issue... Thanks, Clemens -- 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: Btrfsck errors (fs tree 565 refs 125 not found) - how serious
Hi again, I am able to induce the btrfsck errors I experienced using a synthetic workload on a fresh filesystem with linux-3.10.0.rc2. However as filing the bug-report would take quite some time (uploading 512mb trace-files, writing a short read-me, ...) I wonder whether this is an issue woth of reporting, or maybe just caused by an outdated version of btrfsck (I am using btrfs-progs-0.20.rc1.20130308git704a08c-1). Regards, Clemens > fs tree 565 refs 125 not found > unresolved ref root 807 dir 813347 index 277 namelen 39 name > snapshot_1368273601_2013-05-11_14:00:01 error 600 .. -- 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
Hi, >> 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. Most likely the file is heavily fragmented due to COW. Have you tried to manually defrag the filesystem and turn on autodefrag? Regards, Clemens -- 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
Btrfsck errors (fs tree 565 refs 125 not found) - how serious
Hi, For about 3 weeks I've been using btrfs on my desktop machine, using the snapshot-functionality quite a lot. Today I ran btrfsck and got about ~10MB of output which looks like: fs tree 565 refs 125 not found unresolved ref root 807 dir 813347 index 277 namelen 39 name snapshot_1368273601_2013-05-11_14:00:01 error 600 unresolved ref root 808 dir 813347 index 277 namelen 39 name snapshot_1368273601_2013-05-11_14:00:01 error 600 ... fs tree 566 refs 125 not found unresolved ref root 807 dir 813347 index 278 namelen 39 name snapshot_1368274201_2013-05-11_14:10:01 error 600 unresolved ref root 808 dir 813347 index 278 namelen 39 name snapshot_1368274201_2013-05-11_14:10:01 error 600 .. while the log contained a lot of different values for "fs tree", the refs which were not found stays fairly constant: refs: 125, 397, 398, 406, 407, 420 How serious are those issues, should I be worried? Would it help if I find ways to reproduce this behaviour on a fresh btrfs filesystem? Thank you in advance, Clemens -- 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 (general) raid for other filesystems?
Hi Martin, > So, an interesting variation could be to have filesystem level raid > operating on ext4 or nilfs or whatever... Would that be a sensible idea? Thats already supported by using LVM. What do you think you would gain from layering in top of btrfs? - Clemens -- 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
"unlinked 10 orphans" - something to worry about?
Hi, I frequently get messages like "unlinked 10 orphans" in syslog (running linux 3.9.1), although I have never had a power outage nor a kernel crash. Is this something to worry about, or just a usual clean-up information? Thank you in advance, Clemens -- 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
Can btrfs cope with a high number of snapshpts (continuous snapshotting)?
Hi, I am looking for a file-system which is able to provide continuous snapshotting like some log-structured file-systems do. The btrfs snapshot-mechanism seems to be what I am looking for, in combination with a daemon monitoring the free space it should be possible to create a snapshot every 15min and delete snapshots as the free space is below some threshold. Is btrfs suitable for such a high number of snapshots, or will it have negative implications (like huge metadata, ...)? Thank you in advance, Clemens -- 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: "No space left on device" although df reports only 55% in use
Hi Hugo, >> # btrfs filesystem df . >> Data: total=28.22GB, used=14.25GB >> System, DUP: total=8.00MB, used=12.00KB >> System: total=4.00MB, used=0.00 >> Metadata, DUP: total=1.50GB, used=1.16GB > >Your metadata is close to full -- we need quite a lot of working > space to CoW into. You (probably) have the full disk allocated to > chunks, and too much is allocated to data; not enough to metadata. You > need o balance, with a filter for the unused data chunks. See the > section in the FAQ on the wiki about full filesystems. (Sorry for not > finding the link, I'm on a restricted connection right now) I'll re-run the test on a filesystem created with -M (metadata and normal data combined). As far as I understand it shouldn't run in the same problem. > Almost 400MB are not sufficient to do simple touch? What is it doing? I have to admit that thought occurred to me too ;) Regards, Clemens -- 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: "No space left on device" although df reports only 55% in use
Hi again, I wonder if this is the intended behaviour or some known issue? Otherwise I could provide a tool written by a friend of mine which can trigger this issue within a few minutes on a a fresh btrfs partition. Its basically a file-system aging tester, which replays some real-world logs taken from NFS file servers. Regards, Clemens -- 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
"No space left on device" although df reports only 55% in use
Hi, I am using a btrfs loopback mounted file with lzo-compression on Linux-3.7.9, and I ran into "No space left on device" messages, although df reports only 55% of space is used: # touch testfile touch: cannot touch `testfile': No space left on device # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop0 32768000 17383924 14649172 55% /home/ce/anditest # btrfs filesystem df . Data: total=28.22GB, used=14.25GB System, DUP: total=8.00MB, used=12.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.50GB, used=1.16GB Metadata: total=8.00MB, used=0.00 Any ideas what is going wrong here? Thank you in advance, Clemens -- 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: brtfs on top of dmcrypt with SSD -> Trim or no Trim
Hi, > Not using TRIM on my Crucial RealSSD C300 256GB is most likely what caused > its garbage collection algorithm to fail (killing the drive and all its > data), and it was also causing BRTFS to hang badly when I was getting > within 10GB of the drive getting full. Funny thing, as without TRIM the drive does not even know how "full" it is ;) - Clemens -- 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: SSD format/mount parameters questions
> I would not buy anything else > than intel. I have about 26 of them for years now (both in servers and > workstations, several series), and never had an issue. Two of my > colleagues have OCZ, and both had to RMA them. I guess it boils down wether you want intel also to rule the SSD market in the long term, as they do with PC processors... Comparing intel SSDs with OCZ is not that fair, as OCZ has always been low-priced bleeding edge stuff. Usually ratings at Amazon are a good indicator how reliable the product in question is. -- 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 3.3.4 damages filesystem (?)
Hi Helmut, >> But where's the gain? If a disk fails I have a lot of tools for >> repairing an ext2/3/4 system. Nope, when a disk in your ext4 raid0 array fails, you are just as doomed. > But when I use ext2/3/4 I neither need RAID0 nor do I need LVM. You can use btrfs, without using its raid capabilities. Face it, you used an experimental filesystem and you configured it the wrong way. Btrfs is not the one to blame here. - Clemens -- 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
Can btrfs silently repair read-error in raid1
Hi, I have a quite unreliable SSD here which develops some bad blocks from time to time which result in read-errors. Once the block is written to again, its remapped internally and everything is fine again for that block. Would it be possible to create 2 btrfs partitions on that drive and use it in RAID1 - with btrfs silently repairing read-errors when they occur? Would it require special settings, to not fallback to read-only mode when a read-error occurs? Thank you in advance, Clemens -- 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: brtfs on top of dmcrypt with SSD. No corruption iff write cache off?
Hi, > "-o discard" is supported, but can have some negative consequences on > performance on some SSDs or at least whether it adds worthwhile performance > is up for debate The problem is, that TRIM can't be benchmarked in a traditional way - by running one run with TRIM and another one without and later comparing numbers. Sure, enabling TRIM causes your benchmarks to run a bit slower in the first place (as the TRIM commands need to be generated and interpreted by the SSD, which is not free) - however without TRIM the SSD won't have any clue what data is "dead" and what needs to be rescued until you overwrite it. On my SandForce SSD I had disabled TRIM (because those drives are known for the good recovery without TRIM), and for now the SSD is in the following state: dd oflag=sync if=/some_large_file_in_page_cache of=testfile bs=4M 567558236 bytes (568 MB) copied, 23.7798 s, 23.9 MB/s 233 SandForce_Internal 0x 000 000 000Old_age Offline - 3968 241 Lifetime_Writes_GiB 0x0032 000 000 000Old_age Always - 1280 So that drive is writing at 24mb/s and has a write amplification of 3.1 - usually you see values between one and two. Completly "normal" desktop useage. - Clemens -- 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: Honest timeline for btrfsck
Any update on the state of btrfschk? Thanks, Clemens 2011/10/31 David Summers : > On 05/10/11 07:16, Chris Mason wrote: >> >> >> So over the next two weeks I'm juggling the merge window and the fsck >> release. My goal is to demo fsck at linuxcon europe. Thanks again for >> all of your patience and help with Btrfs! >> > Any chance of a copy of your talk at linuxcon? ;) > > David. > > > -- > 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 -- 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: Honest timeline for btrfsck
+1 2011/9/27 Jeff Putney : > On Thu, Aug 18, 2011 at 3:50 PM, Chris Mason wrote: >> I had hoped to get #1 out the door before I left on vacation and I still >>might >> post it tonight. >> >> -chris > > I don't think this is the honest time line that people were looking > for. Instead of playing more guessing games, how about we just get > that source checked in so we can get more eyeballs on it. > -- > 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 > -- 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 fsck tool
Well, the missing file-system checker is the main reason I don't use btrfs in production environments. The other issue are servere performance problems in corner cases (e.g. when deleting 15GB data takes 100% cpu and hours) - Clemens 2011/3/8 Peter Stuge : > Hi, > > Alexey A Nikitin wrote: >> I went experimenting with btrfs RAID0 on my USB setup .. because >> I'm a reckless experimenter when it doesn't involve production >> systems. > > I encountered the same broken root node issue. (see thread resize ate > my root node) and I'd like to understand it better. Hopefully there > will come something out of this. I'm surprised that my resize broke > the filesystem for mounting, when it looked good right after the > resize. > > When I looked through the archive and found your thread I started > thinking, and I am not absolutely sure if there was some disk > activity when I cut power to my system, but I believe there was not. > (I ran reboot, but soft poweroff doesn't work with recent kernels. At > the Rebooting system message I switched hard power off.) > > > //Peter > -- > 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 > -- 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: Summer of Code project idea
Hi Chris, > I think there are a ton of good summer of code ideas for Btrfs, but the > windows driver option isn't quite at the top of my list. It isn't that > I have something against windows, but there's a ton of work to be done > on the Linux side that I'd rather concentrate on first ;) Hmm, somehow I expected this answer :/ I understand that organizations prefer projects working on their internals, and the suggested project would only glue tons of code together. Well, maybe in 2012 ;) Thanks, Clemens -- 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
Summer of Code project idea
Hi, Will btrfs/oracle mentor students for this year's "Google Summer of Code 2011"? I would like to work on a Windows-IFS driver which uses coLinux as a "backend" - and therefor support all Filesystems the Linux kernel has drivers for. Although not as cool as a native btrfs driver for windows, in the long term this could be even more profitable for btrfs - without any porting effort the latest btrfs-features could be used by the Windows-driver too, without time consuming code-sync. If you find the project-idea cool and/or would like to mentor me, please let me know. Thanks, Clemens Eisserer -- 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
null pointer dereference in iov_iter_copy_from_user_atomic while updating rpm packages
Hi, While updating my fedora rawhide installation, I got the Ooops listed at the end of the Email. Is this a known bug (I didn't find anything specific), or should I file a bug? Thank you in advance, Clemens Feb 10 10:59:45 testbox kernel: [ 524.495751] BUG: unable to handle kernel NULL pointer dereference at (null) Feb 10 10:59:45 testbox kernel: [ 524.496006] IP: [] kmap_atomic_prot+0x1c/0x111 Feb 10 10:59:45 testbox kernel: [ 524.496006] *pde = Feb 10 10:59:45 testbox kernel: [ 524.496006] Oops: [#1] SMP Feb 10 10:59:45 testbox kernel: [ 524.496006] last sysfs file: /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map Feb 10 10:59:45 testbox kernel: [ 524.496006] Modules linked in: sunrpc cpufreq_ondemand acpi_cpufreq mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_hda_codec_si3054 snd_hda_codec_realtek arc4 snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device iwl3945 snd_pcm iwlcore mac80211 snd_timer ppdev e1000e snd cfg80211 parport_pc soundcore iTCO_wdt toshiba_bluetooth joydev parport snd_page_alloc toshiba_acpi microcode iTCO_vendor_support sparse_keymap rfkill uinput ipv6 btrfs zlib_deflate libcrc32c sdhci_pci sdhci firewire_ohci mmc_core firewire_core crc_itu_t yenta_socket i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] Feb 10 10:59:45 testbox kernel: [ 524.496006] Feb 10 10:59:45 testbox kernel: [ 524.496006] Pid: 1465, comm: build-locale-ar Not tainted 2.6.38-0.rc3.git4.1.fc15.i686 #1 Portable PC/Tecra A8 Feb 10 10:59:45 testbox kernel: [ 524.496006] EIP: 0060:[] EFLAGS: 00210202 CPU: 0 Feb 10 10:59:45 testbox kernel: [ 524.496006] EIP is at kmap_atomic_prot+0x1c/0x111 Feb 10 10:59:45 testbox kernel: [ 524.496006] EAX: f1d56000 EBX: f1d57eb8 ECX: EDX: 0163 Feb 10 10:59:45 testbox kernel: [ 524.496006] ESI: EDI: 0163 EBP: f1d57de8 ESP: f1d57dd4 Feb 10 10:59:45 testbox kernel: [ 524.496006] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Feb 10 10:59:45 testbox kernel: [ 524.496006] Process build-locale-ar (pid: 1465, ti=f1d56000 task=f1d1f110 task.ti=f1d56000) Feb 10 10:59:45 testbox kernel: [ 524.496006] Stack: Feb 10 10:59:45 testbox kernel: [ 524.496006] f1d57df0 f1d57eb8 1000 f1d57df0 c04268aa f1d57e08 Feb 10 10:59:45 testbox kernel: [ 524.496006] c04ab3cd 012c 1000 f1d57e2c f8217b41 012c Feb 10 10:59:45 testbox kernel: [ 524.496006] 1010 0002 1000 f1d57eb8 113c f1d57edc f8218129 Feb 10 10:59:45 testbox kernel: [ 524.496006] Call Trace: Feb 10 10:59:45 testbox kernel: [ 524.496006] [] __kmap_atomic+0x13/0x15 Feb 10 10:59:45 testbox kernel: [ 524.496006] [] iov_iter_copy_from_user_atomic+0x28/0x6c Feb 10 10:59:45 testbox kernel: [ 524.496006] [] btrfs_copy_from_user.isra.6+0x5c/0x96 [btrfs] Feb 10 10:59:45 testbox kernel: [ 524.496006] [] btrfs_file_aio_write+0x480/0x79b [btrfs] Feb 10 10:59:45 testbox kernel: [ 524.496006] [] ? mem_cgroup_update_page_stat+0x1a/0xd4 Feb 10 10:59:45 testbox kernel: [ 524.496006] [] do_sync_write+0x96/0xcf Feb 10 10:59:45 testbox kernel: [ 524.496006] [] ? rw_verify_area+0xd0/0xf3 Feb 10 10:59:45 testbox kernel: [ 524.496006] [] vfs_write+0x8f/0xd7 Feb 10 10:59:45 testbox kernel: [ 524.496006] [] ? do_sync_write+0x0/0xcf Feb 10 10:59:45 testbox kernel: [ 524.496006] [] sys_write+0x42/0x63 Feb 10 10:59:45 testbox kernel: [ 524.496006] [] syscall_call+0x7/0xb Feb 10 10:59:45 testbox kernel: [ 524.496006] Code: 26 00 8b 15 08 b9 af c0 e8 58 f9 ff ff 5d c3 55 89 e5 57 56 53 83 ec 08 3e 8d 74 26 00 89 c6 89 e0 25 00 e0 ff ff 89 d7 ff 40 14 <8b> 06 c1 e8 1e 69 c0 80 03 00 00 05 00 07 a3 c0 e8 49 fe ff ff Feb 10 10:59:45 testbox kernel: [ 524.496006] EIP: [] kmap_atomic_prot+0x1c/0x111 SS:ESP 0068:f1d57dd4 Feb 10 10:59:45 testbox kernel: [ 524.496006] CR2: Feb 10 10:59:45 testbox kernel: [ 524.582447] ---[ end trace e16f2400ae6eb809 ]--- Feb 10 10:59:45 testbox kernel: [ 524.584816] note: build-locale-ar[1465] exited with preempt_count 2 Feb 10 10:59:45 testbox kernel: [ 524.584819] BUG: sleeping function called from invalid context at kernel/rwsem.c:21 Feb 10 10:59:45 testbox kernel: [ 524.584822] in_atomic(): 1, irqs_disabled(): 0, pid: 1465, name: build-locale-ar Feb 10 10:59:45 testbox kernel: [ 524.584828] Pid: 1465, comm: build-locale-ar Tainted: G D 2.6.38-0.rc3.git4.1.fc15.i686 #1 Feb 10 10:59:45 testbox kernel: [ 524.584830] Call Trace: Feb 10 10:59:45 testbox kernel: [ 524.584835] [] ? __might_sleep+0xdd/0xe4 Feb 10 10:59:45 testbox kernel: [ 524.584839] [] ? down_read+0x1c/0x30 Feb 10 10:59:45 testbox kernel: [ 524.584843] [] ? acct_collect+0x3e/0x138 Feb 10 10:59:45 testbox kernel: [ 524.584847] [] ? do_exit+0x1d0/0x62c Feb 10 10:59:45 testbox kernel: [ 524.584850] [] ? kmsg_dump+0x3a/0xb6 Feb 10 10:59:45 testbox kernel: [ 524.584853] [] ? oops_end+0xa2/0xa8 Feb 10
Re: [GIT PULL] Btrfs updates
> E.g. suppose you have a LZO compressed file, then a program rewrites some > data which is in the middle of the file, and suppose the newly written data > is less compressible. Any idea how this is handled? I would be interested in the answer as well. Thank you in advance, Clemens -- 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: slow deletion of files
Forgot to mention, I filed already a report for this problem: https://bugzilla.kernel.org/show_bug.cgi?id=16117 However, like the other btrfs bug I filed, it was never looked at - so I decided it was a waste of time to file bugs against it. - Clemens -- 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: slow deletion of files
Hi, >> during my testing of btrfs I found out, >> that deletion of directory with many files (many millions) takes vry >> long (it is running two weeks now and did not finish). Same for me. I moved back to ext4 on my backup-drive because deleting old backups created with BackInTime took forever to delete. Another reason I moved away was btrfs corrupted, and btrfsck is still not able to repair it. I really like btrfs but in my opinion it has still a long road to go and declaring it stable in 2.6.35 is quite optimistic at best. - Clemens -- 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: Music-files suddenly not recognized anymore, empty files - Btrfschk reports errors
Hi, > have you taken any snapshots? you could pull them from there maybe. No snapshots unfourtunatly. I wonder what could have caused those filesystem errors. The only "unusual" thing I did was to mount it with "compress", but other than that - i didn't even stress it a lot. > btrfsck is not able to repair anything yet. Oh, sad to hear that. Ok I guess that means backing up my data and re-formating is probably the best I can do. Thanks, Clemens -- 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
Music-files suddenly not recognized anymore, empty files - Btrfschk reports errors
Hi, Recently Amarok started to reject some of music files. Some files seem to be simply corrupted (mplayer is still able to play them), other have zero length. Btrfsck reports: root 5 inode 1371 errors 400 found 42498768896 bytes used err is 1 total csum bytes: 41015664 total tree bytes: 498728960 total fs tree bytes: 406466560 btree space waste bytes: 110792472 file data blocks allocated: 271306133504 referenced 46886879232 Btrfs Btrfs v0.19 Anything I can do to repair those errors? Thank you in advance, Clemens -- 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
