Re: Kernel error during btrfs balance
Hi,
It took me a couple of days, because I needed to patch my kernel first
and then issue a rebalance, which ran for more than two days.
Nevertheless, the rebalance succeeded without any kernel BUG-messages,
so apparently your patch works!
I noticed that at first, the messages were like this:
[79329.526490] btrfs: found 1939 extents
[79375.950834] btrfs: found 1939 extents
[79376.083599] btrfs: relocating block group 352220872704 flags 1
[80052.940435] btrfs: found 3786 extents
[80108.439657] btrfs: found 3786 extents
[80112.325548] btrfs: relocating block group 351147130880 flags 1
Just like I saw during previous balance-runs. Then all of a sudden the
messages changed to:
[104178.827594] btrfs allocation failed flags 1, wanted 2013265920
[104178.827599] space_info has 4271198208 free, is not full
[104178.827602] space_info total=214748364800, used=210440957952,
pinned=0, reserved=36208640, may_use=3168993280, readonly=0
[104178.827606] block group 1107296256 has 5368709120 bytes, 5368582144
used 0 pinned 0 reserved
[104178.827610] entry offset 1778384896, bytes 86016, bitmap yes
[104178.827612] entry offset 1855827968, bytes 20480, bitmap no
[104178.827614] entry offset 1855852544, bytes 20480, bitmap no
[104178.827617] block group has cluster?: no
[104178.827618] 0 blocks of free space at or bigger than bytes is
[104178.827621] block group 8623489024 has 5368709120 bytes, 5368705024
used 0 pinned 0 reserved
[104178.827624] entry offset 8891924480, bytes 4096, bitmap yes
[104178.827626] block group has cluster?: no
[104178.827628] 0 blocks of free space at or bigger than bytes is
[104178.827631] block group 17213423616 has 5368709120 bytes, 5368709120
used 0 pinned 0 reserved
[104178.827634] block group has cluster?: no
And so on.
Does this indicate an error of any sort, or is this expected behaviour?
Kind regards,
Erik.
On 01/21/2011 10:19 AM, Yan, Zheng wrote:
please try patch attached below, Thanks.
---
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index b37d723..49d6b13 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1158,6 +1158,7 @@ static int clone_backref_node(struct
btrfs_trans_handle *trans,
new_node-bytenr = dest-node-start;
new_node-level = node-level;
new_node-lowest = node-lowest;
+ new_node-checked = 1;
new_node-root = dest;
if (!node-lowest) {
---
On Fri, Jan 21, 2011 at 4:50 PM, Erik Logtenberg e...@logtenberg.eu wrote:
Hi,
I hit the same bug again I think:
[291835.724344] [ cut here ]
[291835.724376] kernel BUG at fs/btrfs/relocation.c:836!
[291835.724401] invalid opcode: [#1] SMP
[291835.724424] last sysfs file:
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map
[291835.724461] CPU 0
[291835.724472] Modules linked in: uvcvideo snd_usb_audio
snd_usbmidi_lib videodev v4l1_compat snd_rawmidi v4l2_compat_ioctl32
btrfs zlib_deflate libcrc32c sha256_generic cryptd aes_x86_64
aes_generic cbc dm_crypt tun ebtable_nat ebtables ipt_MASQUERADE
iptable_nat nf_nat bridge stp llc nfsd lockd nfs_acl auth_rpcgss
exportfs nls_utf8 cifs fscache sunrpc cpufreq_ondemand acpi_cpufreq
freq_table mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
ip6table_filter ip6_tables ipv6 kvm_intel kvm dummy uinput
snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_seq
snd_seq_device e1000e snd_pcm snd_timer i2c_i801 snd shpchp iTCO_wdt
iTCO_vendor_support soundcore dell_wmi sparse_keymap snd_page_alloc
serio_raw joydev wmi dcdbas microcode usb_storage uas raid1 pata_acpi
ata_generic radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last
unloaded: scsi_wait_scan]
[291835.725002]
[291835.725013] Pid: 27386, comm: btrfs Tainted: G I
2.6.37-2.fc15.x86_64 #1
[291835.725062] RIP: 0010:[a0565237] [a0565237]
build_backref_tree+0x473/0xd6d [btrfs]
[291835.725126] RSP: 0018:8800373bf9c8 EFLAGS: 00010246
[291835.725152] RAX: 8801367d5100 RBX: 88020b110880 RCX:
0040
[291835.725186] RDX: 0030 RSI: 006dd08d3000 RDI:
880100069820
[291835.725219] RBP: 8800373bfaf8 R08: 8050 R09:
8800373bf980
[291835.725253] R10: 8800373bf918 R11: 88020b110880 R12:
8801367d5100
[291835.725254] R13: 88012c0a24c0 R14: 88021e2013f0 R15:
88021e201cf0
[291835.725254] FS: 7fcb1a6cc760() GS:8800bfa0()
knlGS:
[291835.725254] CS: 0010 DS: ES: CR0: 8005003b
[291835.725254] CR2: 02feeeb8 CR3: 0001c2943000 CR4:
000426e0
[291835.725254] DR0: DR1: DR2:
[291835.725254] DR3: DR6: 0ff0 DR7:
0400
[291835.725254] Process btrfs (pid: 27386, threadinfo 8800373be000,
task 88022452ae40)
[291835.725254] Stack:
[291835.725254] ea0004b5a470 ea00 8800373bf9f8
Re: Kernel error during btrfs balance
On Wed, Jan 26, 2011 at 10:04:02AM +0100, Erik Logtenberg wrote: Hi, It took me a couple of days, because I needed to patch my kernel first and then issue a rebalance, which ran for more than two days. Nevertheless, the rebalance succeeded without any kernel BUG-messages, so apparently your patch works! I noticed that at first, the messages were like this: [79329.526490] btrfs: found 1939 extents [79375.950834] btrfs: found 1939 extents [79376.083599] btrfs: relocating block group 352220872704 flags 1 [80052.940435] btrfs: found 3786 extents [80108.439657] btrfs: found 3786 extents [80112.325548] btrfs: relocating block group 351147130880 flags 1 Just like I saw during previous balance-runs. Then all of a sudden the messages changed to: [104178.827594] btrfs allocation failed flags 1, wanted 2013265920 [104178.827599] space_info has 4271198208 free, is not full [104178.827602] space_info total=214748364800, used=210440957952, pinned=0, reserved=36208640, may_use=3168993280, readonly=0 [104178.827606] block group 1107296256 has 5368709120 bytes, 5368582144 used 0 pinned 0 reserved [104178.827610] entry offset 1778384896, bytes 86016, bitmap yes [104178.827612] entry offset 1855827968, bytes 20480, bitmap no [104178.827614] entry offset 1855852544, bytes 20480, bitmap no [104178.827617] block group has cluster?: no [104178.827618] 0 blocks of free space at or bigger than bytes is [104178.827621] block group 8623489024 has 5368709120 bytes, 5368705024 used 0 pinned 0 reserved [104178.827624] entry offset 8891924480, bytes 4096, bitmap yes [104178.827626] block group has cluster?: no [104178.827628] 0 blocks of free space at or bigger than bytes is [104178.827631] block group 17213423616 has 5368709120 bytes, 5368709120 used 0 pinned 0 reserved [104178.827634] block group has cluster?: no And so on. Does this indicate an error of any sort, or is this expected behaviour? As far as I know, it means that you've run out of space, and not every block group has been rewritten by the balance process. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- In one respect at least, the Martians are a happy people: --- they have no lawyers. signature.asc Description: Digital signature
Re: Kernel error during btrfs balance
[104178.827624] entry offset 8891924480, bytes 4096, bitmap yes [104178.827626] block group has cluster?: no [104178.827628] 0 blocks of free space at or bigger than bytes is [104178.827631] block group 17213423616 has 5368709120 bytes, 5368709120 used 0 pinned 0 reserved [104178.827634] block group has cluster?: no And so on. Does this indicate an error of any sort, or is this expected behaviour? As far as I know, it means that you've run out of space, and not every block group has been rewritten by the balance process. Hugo. It is a 300GB volume with 79GB free. So hardly out of space. Moreover, I started the balance operation with the sole purpose of reclaiming some free space. The volume had like 40GB less free space when balance started, which was used by / reserved for Metadata. Kind regards, Erik. -- 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 error during btrfs balance
Yesterday I reported a similar problem in this mailing list, in the thread version. Running kernel 2.6.37 didn't show this error, but running kernel 2.6.38- rc2 ended with errors. Viele Gruesse! Helmut Ah, indeed, just like you I use 2.6.38-rc2. Or to be more precise: 2.6.38-0.rc2.git0.1.fc14.x86_64, which is the latest rawhide kernel, with one additional patch, being the oneliner from Zheng Yan. Kind regards, Erik. -- 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 error during btrfs balance
please try patch attached below, Thanks.
---
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index b37d723..49d6b13 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1158,6 +1158,7 @@ static int clone_backref_node(struct
btrfs_trans_handle *trans,
new_node-bytenr = dest-node-start;
new_node-level = node-level;
new_node-lowest = node-lowest;
+ new_node-checked = 1;
new_node-root = dest;
if (!node-lowest) {
---
On Fri, Jan 21, 2011 at 4:50 PM, Erik Logtenberg e...@logtenberg.eu wrote:
Hi,
I hit the same bug again I think:
[291835.724344] [ cut here ]
[291835.724376] kernel BUG at fs/btrfs/relocation.c:836!
[291835.724401] invalid opcode: [#1] SMP
[291835.724424] last sysfs file:
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map
[291835.724461] CPU 0
[291835.724472] Modules linked in: uvcvideo snd_usb_audio
snd_usbmidi_lib videodev v4l1_compat snd_rawmidi v4l2_compat_ioctl32
btrfs zlib_deflate libcrc32c sha256_generic cryptd aes_x86_64
aes_generic cbc dm_crypt tun ebtable_nat ebtables ipt_MASQUERADE
iptable_nat nf_nat bridge stp llc nfsd lockd nfs_acl auth_rpcgss
exportfs nls_utf8 cifs fscache sunrpc cpufreq_ondemand acpi_cpufreq
freq_table mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
ip6table_filter ip6_tables ipv6 kvm_intel kvm dummy uinput
snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_seq
snd_seq_device e1000e snd_pcm snd_timer i2c_i801 snd shpchp iTCO_wdt
iTCO_vendor_support soundcore dell_wmi sparse_keymap snd_page_alloc
serio_raw joydev wmi dcdbas microcode usb_storage uas raid1 pata_acpi
ata_generic radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last
unloaded: scsi_wait_scan]
[291835.725002]
[291835.725013] Pid: 27386, comm: btrfs Tainted: G I
2.6.37-2.fc15.x86_64 #1
[291835.725062] RIP: 0010:[a0565237] [a0565237]
build_backref_tree+0x473/0xd6d [btrfs]
[291835.725126] RSP: 0018:8800373bf9c8 EFLAGS: 00010246
[291835.725152] RAX: 8801367d5100 RBX: 88020b110880 RCX:
0040
[291835.725186] RDX: 0030 RSI: 006dd08d3000 RDI:
880100069820
[291835.725219] RBP: 8800373bfaf8 R08: 8050 R09:
8800373bf980
[291835.725253] R10: 8800373bf918 R11: 88020b110880 R12:
8801367d5100
[291835.725254] R13: 88012c0a24c0 R14: 88021e2013f0 R15:
88021e201cf0
[291835.725254] FS: 7fcb1a6cc760() GS:8800bfa0()
knlGS:
[291835.725254] CS: 0010 DS: ES: CR0: 8005003b
[291835.725254] CR2: 02feeeb8 CR3: 0001c2943000 CR4:
000426e0
[291835.725254] DR0: DR1: DR2:
[291835.725254] DR3: DR6: 0ff0 DR7:
0400
[291835.725254] Process btrfs (pid: 27386, threadinfo 8800373be000,
task 88022452ae40)
[291835.725254] Stack:
[291835.725254] ea0004b5a470 ea00 8800373bf9f8
8800373bfaa8
[291835.725254] 88005faafbb0 880100069808
880100069d78
[291835.725254] 88012c0a2aa0 880100069820 88020b1108c0
880100069d80
[291835.725254] Call Trace:
[291835.725254] [a0565c91] relocate_tree_blocks+0x160/0x478
[btrfs]
[291835.725254] [a056463d] ? add_tree_block+0x11e/0x13e [btrfs]
[291835.725254] [a0566b45] relocate_block_group+0x1e3/0x490
[btrfs]
[291835.725254] [8103edb9] ? should_resched+0xe/0x2e
[291835.725254] [a0566f39]
btrfs_relocate_block_group+0x147/0x28a [btrfs]
[291835.725254] [a054e52a]
btrfs_relocate_chunk.clone.40+0x61/0x4ab [btrfs]
[291835.725254] [a05152d4] ? btrfs_item_key+0x1e/0x20 [btrfs]
[291835.725254] [a05152f0] ? btrfs_item_key_to_cpu+0x1a/0x36
[btrfs]
[291835.725254] [a054c2a8] ? read_extent_buffer+0xc3/0xe3 [btrfs]
[291835.725254] [a05154e6] ?
btrfs_header_nritems.clone.12+0x17/0x1c [btrfs]
[291835.725254] [a054cff6] ? btrfs_item_key_to_cpu+0x2a/0x46
[btrfs]
[291835.725254] [a055045e] btrfs_balance+0x1a3/0x1f0 [btrfs]
[291835.725254] [8112bce5] ? do_filp_open+0x226/0x5c8
[291835.725254] [a0556773] btrfs_ioctl+0x641/0x846 [btrfs]
[291835.725254] [811f3ed1] ? file_has_perm+0xa5/0xc7
[291835.725254] [8112e091] do_vfs_ioctl+0x4b1/0x4f2
[291835.725254] [8112e128] sys_ioctl+0x56/0x7a
[291835.725254] [8100acc2] system_call_fastpath+0x16/0x1b
[291835.725254] Code: 48 8b 45 89 49 8d 7d 10 48 8d 75 b0 49 89 44 24 18
8a 43 70 ff c0 41 88 44 24 70 e8 f7 c3 ff ff eb 17 f6 40 71 10 49 89 c4
75 02 0f 0b 49 8d 45 10 49 89 45 10 49 89 45 18 48 8b b5 20 ff ff ff
[291835.725254] RIP [a0565237] build_backref_tree+0x473/0xd6d
[btrfs]
[291835.725254] RSP 8800373bf9c8
[291835.738971] ---[ end trace a7919e7f17c0a727
Re: Kernel error during btrfs balance
On Tue, Jan 18, 2011 at 9:22 PM, Erik Logtenberg e...@logtenberg.eu wrote: On 01/18/2011 01:54 AM, Yan, Zheng wrote: On Mon, Jan 17, 2011 at 10:14 PM, Erik Logtenberg e...@logtenberg.eu wrote: Hi, btrfs balance results in: http://pastebin.com/v5j0809M My system: fully up-to-date Fedora 14 with rawhide kernel to make btrfs balance do useful stuff to my free space: kernel-2.6.37-2.fc15.x86_64 btrfs-progs-0.19-12.fc14.x86_64 Filesystem had 0 bytes free, should be 45G, so on darklings advice I ran btrfs balance on the fs, while doing heavy I/O (re-running 5 backup jobs that had failed due to ENOSP). Up until the crash, btrfs balance did retrieve a couple of Gigs free space though, so that part of the plan worked just fine. Please try 2.6.36 kernel. Thanks for your (short) advice. Could you please elaborate. I was in fact using a 2.6.35.10-74.fc14.x86_64 kernel before, but darkling adviced me to switch to a newer kernel to reclaim free space by balancing -- the idea was that newer kernels have better balancing implementation, more effective at reclaiming free space. Now your advice is to take a small step back again, from 2.6.37 to 2.6.36 (which is still higher than the 2.6.35 I was using before). Is that because you think that 2.6.37 may have introduced the bug that I ran into? Do you think that 2.6.36 is still recent enough to have the effective balancing so that I will in fact be able to reclaim some free space? Or is is just a shot in the dark with no reasoning whatsoever ;) Please don't feel offended, but from your 4-word sentence I really can't tell. Just try narrowing down the bug, because I never saw bug like this before. -- 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 error during btrfs balance
Hi, btrfs balance results in: http://pastebin.com/v5j0809M My system: fully up-to-date Fedora 14 with rawhide kernel to make btrfs balance do useful stuff to my free space: kernel-2.6.37-2.fc15.x86_64 btrfs-progs-0.19-12.fc14.x86_64 Filesystem had 0 bytes free, should be 45G, so on darklings advice I ran btrfs balance on the fs, while doing heavy I/O (re-running 5 backup jobs that had failed due to ENOSP). Up until the crash, btrfs balance did retrieve a couple of Gigs free space though, so that part of the plan worked just fine. Thanks, Erik. -- 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 error during btrfs balance
Hi, Please find attached the error log, for future reference. Forgot to mention: I could still use the system after this error, so it was not a complete fatal error in that regard. All active processes (mostly rsync) were hanging in state D though, so I couldn't kill them anymore. Also the FS was not umountable. So I still had to reboot. Thanks, Erik. On 01/17/2011 03:14 PM, Erik Logtenberg wrote: Hi, btrfs balance results in: http://pastebin.com/v5j0809M My system: fully up-to-date Fedora 14 with rawhide kernel to make btrfs balance do useful stuff to my free space: kernel-2.6.37-2.fc15.x86_64 btrfs-progs-0.19-12.fc14.x86_64 Filesystem had 0 bytes free, should be 45G, so on darklings advice I ran btrfs balance on the fs, while doing heavy I/O (re-running 5 backup jobs that had failed due to ENOSP). Up until the crash, btrfs balance did retrieve a couple of Gigs free space though, so that part of the plan worked just fine. Thanks, Erik. -- 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 [ 5225.236087] [ cut here ] [ 5225.236112] kernel BUG at fs/btrfs/relocation.c:836! [ 5225.236131] invalid opcode: [#1] SMP [ 5225.236151] last sysfs file: /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map [ 5225.236178] CPU 0 [ 5225.236186] Modules linked in: ipt_LOG xt_limit btrfs zlib_deflate libcrc32c sha256_generic cryptd aes_x86_64 aes_generic cbc dm_crypt tun ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat bridge stp llc nfsd lockd nfs_acl auth_rpcgss exportfs nls_utf8 cifs fscache sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 kvm_intel kvm dummy uinput snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm shpchp snd_timer dell_wmi snd soundcore sparse_keymap snd_page_alloc dcdbas i2c_i801 e1000e iTCO_wdt iTCO_vendor_support joydev wmi serio_raw microcode usb_storage uas raid1 pata_acpi ata_generic radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan] [ 5225.236582] [ 5225.236591] Pid: 2934, comm: btrfs Tainted: G I 2.6.37-2.fc15.x86_64 #1 [ 5225.236627] RIP: 0010:[lt;a0565237gt;] [lt;a0565237gt;] build_backref_tree+0x473/0xd6d [btrfs] [ 5225.236676] RSP: 0018:8801972af9c8 EFLAGS: 00010246 [ 5225.236695] RAX: 8800aa9ab880 RBX: 8800ac38e300 RCX: 0040 [ 5225.236720] RDX: 0030 RSI: 00254e68 RDI: 88019cfc3020 [ 5225.236745] RBP: 8801972afaf8 R08: 8050 R09: 8801972af970 [ 5225.236770] R10: 8801972af918 R11: 8801972af900 R12: 8800aa9ab880 [ 5225.236794] R13: 88018b186340 R14: 88021fa3bea0 R15: 88021fa3bb40 [ 5225.236820] FS: 7f98476bd760() GS:8800bfa0() knlGS: [ 5225.236848] CS: 0010 DS: ES: CR0: 8005003b [ 5225.236869] CR2: 00a0eb44 CR3: 0001972ab000 CR4: 000426e0 [ 5225.236894] DR0: DR1: DR2: [ 5225.236918] DR3: DR6: 0ff0 DR7: 0400 [ 5225.236943] Process btrfs (pid: 2934, threadinfo 8801972ae000, task 88019ce7c560) [ 5225.236971] Stack: [ 5225.236980] ea0005056ee0 ea00 8801972af9f8 8801972afaa8 [ 5225.237002] 88007b1eae58 88019cfc3008 88019cfc3578 [ 5225.237002] 8801bd12ffe0 88019cfc3020 8800ac38e340 88019cfc3580 [ 5225.237002] Call Trace: [ 5225.237002] [lt;a0565c91gt;] relocate_tree_blocks+0x160/0x478 [btrfs] [ 5225.237002] [lt;a056463dgt;] ? add_tree_block+0x11e/0x13e [btrfs] [ 5225.237002] [lt;a0566b45gt;] relocate_block_group+0x1e3/0x490 [btrfs] [ 5225.237002] [lt;8103edb9gt;] ? should_resched+0xe/0x2e [ 5225.237002] [lt;a0566f39gt;] btrfs_relocate_block_group+0x147/0x28a [btrfs] [ 5225.237002] [lt;a054e52agt;] btrfs_relocate_chunk.clone.40+0x61/0x4ab [btrfs] [ 5225.237002] [lt;a05152d4gt;] ? btrfs_item_key+0x1e/0x20 [btrfs] [ 5225.237002] [lt;a05152f0gt;] ? btrfs_item_key_to_cpu+0x1a/0x36 [btrfs] [ 5225.237002] [lt;a054c2a8gt;] ? read_extent_buffer+0xc3/0xe3 [btrfs] [ 5225.237002] [lt;a05154e6gt;] ? btrfs_header_nritems.clone.12+0x17/0x1c [btrfs] [ 5225.237002] [lt;a054cff6gt;] ? btrfs_item_key_to_cpu+0x2a/0x46 [btrfs] [ 5225.237002] [lt;a055045egt;] btrfs_balance+0x1a3/0x1f0 [btrfs] [ 5225.237002] [lt;8112bce5gt;] ? do_filp_open+0x226/0x5c8 [ 5225.237002] [lt;a0556773gt;] btrfs_ioctl+0x641/0x846 [btrfs] [ 5225.237002] [lt;811f3ed1gt;] ? file_has_perm+0xa5/0xc7 [ 5225.237002] [lt;8112e091gt;]
Re: Kernel error during btrfs balance
Hi, Additionally, I cannot mount the filesystem anymore. mount gives no error messages but hangs in state D. dmesg shows: [ 422.323116] btrfs: use compression Which is a good thing, but it doesn't do anything otherwise. Thanks, Erik. On 01/17/2011 03:31 PM, Erik Logtenberg wrote: Hi, Please find attached the error log, for future reference. Forgot to mention: I could still use the system after this error, so it was not a complete fatal error in that regard. All active processes (mostly rsync) were hanging in state D though, so I couldn't kill them anymore. Also the FS was not umountable. So I still had to reboot. Thanks, Erik. On 01/17/2011 03:14 PM, Erik Logtenberg wrote: Hi, btrfs balance results in: http://pastebin.com/v5j0809M My system: fully up-to-date Fedora 14 with rawhide kernel to make btrfs balance do useful stuff to my free space: kernel-2.6.37-2.fc15.x86_64 btrfs-progs-0.19-12.fc14.x86_64 Filesystem had 0 bytes free, should be 45G, so on darklings advice I ran btrfs balance on the fs, while doing heavy I/O (re-running 5 backup jobs that had failed due to ENOSP). Up until the crash, btrfs balance did retrieve a couple of Gigs free space though, so that part of the plan worked just fine. Thanks, Erik. -- 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
