Segfault in "btrfs balance start" due to kernel page allocation failure

Segfault in "btrfs balance start" due to kernel page allocation failure

[Remy Blank]

I have a btrfs filesystem that shows the following errors. This happens
either when writing to the FS or when snapshotting, I'm not sure (this
FS holds my backup, and I write to it with rsync and snapshot afterward).

Jan  8 13:54:33 twin kernel: BTRFS error (device dm-2): error inheriting
props for ino 3828 (root 317): -28
Jan  8 13:54:38 twin kernel: BTRFS error (device dm-2): error inheriting
props for ino 17939 (root 317): -28
Jan  8 13:54:49 twin kernel: BTRFS error (device dm-2): error inheriting
props for ino 26564 (root 317): -28
Jan  8 14:01:07 twin kernel: BTRFS error (device dm-2): error inheriting
props for ino 34014 (root 317): -28
Jan  8 14:01:08 twin kernel: BTRFS error (device dm-2): error inheriting
props for ino 34515 (root 317): -28
Jan  8 14:01:08 twin kernel: BTRFS error (device dm-2): error inheriting
props for ino 34519 (root 317): -28
Jan  8 14:01:19 twin kernel: BTRFS error (device dm-2): error inheriting
props for ino 53644 (root 317): -28
Jan  8 14:01:19 twin kernel: BTRFS error (device dm-2): error inheriting
props for ino 53649 (root 317): -28
Jan  8 14:01:25 twin kernel: BTRFS error (device dm-2): error inheriting
props for ino 56783 (root 317): -28

I ran "btrfs balance start" on the FS, and it terminated with a
segfault, apparently due to a page allocation failure. The machine is
x86_64, running 3.17.7, and has more than enough memory (it's currently
using 600 MiB out of 16 GiB). The kernel log is pasted below. Issuing a
"btrfs balance cancel" blocks in non-interruptible mode, so I'll
probably have trouble unmounting this FS.

Any help appreciated.

-- Remy


Jan  9 12:06:33 twin kernel: btrfs: page allocation failure: order:1,
mode:0x204020
Jan  9 12:06:33 twin kernel: CPU: 1 PID: 3188 Comm: btrfs Not tainted
3.17.7-gentoo #2
Jan  9 12:06:33 twin kernel: Hardware name: Shuttle Inc. DS47D/FS47D,
BIOS 1.00 04/10/2013
Jan  9 12:06:33 twin kernel: ffff8800057f76a0 ffffffff816b0429
0000000000204020 ffffffff811647d7
Jan  9 12:06:33 twin kernel: ffffffff810fd2b9 ffff88041f5e7e00
0000000000000000 0000000200000001
Jan  9 12:06:33 twin kernel: ffff88041f5ea2a8 0000000000000046
0000000000000000 0000000000000000
Jan  9 12:06:33 twin kernel: Call Trace:
Jan  9 12:06:33 twin kernel: [<ffffffff816b0429>] ? dump_stack+0x49/0x6a
Jan  9 12:06:33 twin kernel: [<ffffffff811647d7>] ?
warn_alloc_failed+0xd7/0x130
Jan  9 12:06:33 twin kernel: [<ffffffff810fd2b9>] ?
autoremove_wake_function+0x9/0x30
Jan  9 12:06:33 twin kernel: [<ffffffff81168378>] ?
__alloc_pages_nodemask+0x778/0xb20
Jan  9 12:06:33 twin kernel: [<ffffffff811a8c2c>] ? kmem_getpages+0x6c/0x190
Jan  9 12:06:33 twin kernel: [<ffffffff811aa80f>] ?
fallback_alloc+0x1bf/0x200
Jan  9 12:06:33 twin kernel: [<ffffffff811aaa08>] ?
kmem_cache_alloc+0xf8/0x1a0
Jan  9 12:06:33 twin kernel: [<ffffffff8140aa10>] ? ida_pre_get+0x60/0xe0
Jan  9 12:06:33 twin kernel: [<ffffffff811c0da1>] ? get_anon_bdev+0x21/0x100
Jan  9 12:06:33 twin kernel: [<ffffffff8142f0d8>] ?
__percpu_counter_init+0x68/0x80
Jan  9 12:06:33 twin kernel: [<ffffffff8130f56c>] ?
btrfs_init_fs_root+0xec/0x180
Jan  9 12:06:33 twin kernel: [<ffffffff81310a46>] ?
btrfs_get_fs_root+0xb6/0x240
Jan  9 12:06:33 twin kernel: [<ffffffff8135e6b4>] ? read_fs_root+0x34/0x40
Jan  9 12:06:33 twin kernel: [<ffffffff8135f8e1>] ?
build_backref_tree+0x671/0x1210
Jan  9 12:06:33 twin kernel: [<ffffffff8130d480>] ?
free_root_pointers+0x50/0x50
Jan  9 12:06:33 twin kernel: [<ffffffff81361723>] ?
relocate_tree_blocks+0x1e3/0x600
Jan  9 12:06:33 twin kernel: [<ffffffff8135c2bc>] ? tree_insert+0x4c/0x50
Jan  9 12:06:33 twin kernel: [<ffffffff81362f12>] ?
relocate_block_group+0x3f2/0x670
Jan  9 12:06:33 twin kernel: [<ffffffff81363347>] ?
btrfs_relocate_block_group+0x1b7/0x2c0
Jan  9 12:06:33 twin kernel: [<ffffffff8133a028>] ?
btrfs_relocate_chunk.isra.31+0x58/0x6a0
Jan  9 12:06:33 twin kernel: [<ffffffff812eea71>] ?
btrfs_set_path_blocking+0x31/0x70
Jan  9 12:06:33 twin kernel: [<ffffffff812f3ecd>] ?
btrfs_search_slot+0x4dd/0xae0
Jan  9 12:06:33 twin kernel: [<ffffffff81336478>] ?
read_extent_buffer+0xc8/0x120
Jan  9 12:06:33 twin kernel: [<ffffffff8132ca20>] ?
btrfs_get_token_64+0x50/0xe0
Jan  9 12:06:33 twin kernel: [<ffffffff81335451>] ?
release_extent_buffer+0x21/0xc0
Jan  9 12:06:33 twin kernel: [<ffffffff8133d07e>] ?
btrfs_balance+0x82e/0xe20
Jan  9 12:06:33 twin kernel: [<ffffffff813438ef>] ?
btrfs_ioctl_balance+0x14f/0x340
Jan  9 12:06:33 twin kernel: [<ffffffff81348cfc>] ? btrfs_ioctl+0x58c/0x2b10
Jan  9 12:06:33 twin kernel: [<ffffffff811ba90e>] ?
mem_cgroup_commit_charge+0x5e/0xa0
Jan  9 12:06:33 twin kernel: [<ffffffff81188798>] ?
handle_mm_fault+0x9a8/0xe90
Jan  9 12:06:33 twin kernel: [<ffffffff81036e58>] ?
__do_page_fault+0x1b8/0x450
Jan  9 12:06:33 twin kernel: [<ffffffff8118b9f1>] ? vma_link+0xb1/0xc0
Jan  9 12:06:33 twin kernel: [<ffffffff811cfda7>] ? do_vfs_ioctl+0x2d7/0x4b0
Jan  9 12:06:33 twin kernel: [<ffffffff811cfff9>] ? SyS_ioctl+0x79/0x90
Jan  9 12:06:33 twin kernel: [<ffffffff816b7948>] ? page_fault+0x28/0x30
Jan  9 12:06:33 twin kernel: [<ffffffff816b60ad>] ?
system_call_fastpath+0x1a/0x1f
Jan  9 12:06:33 twin kernel: Mem-Info:
Jan  9 12:06:33 twin kernel: Node 0 DMA per-cpu:
Jan  9 12:06:33 twin kernel: CPU    0: hi:    0, btch:   1 usd:   0
Jan  9 12:06:33 twin kernel: CPU    1: hi:    0, btch:   1 usd:   0
Jan  9 12:06:33 twin kernel: Node 0 DMA32 per-cpu:
Jan  9 12:06:33 twin kernel: CPU    0: hi:  186, btch:  31 usd: 154
Jan  9 12:06:33 twin kernel: CPU    1: hi:  186, btch:  31 usd: 191
Jan  9 12:06:33 twin kernel: Node 0 Normal per-cpu:
Jan  9 12:06:33 twin kernel: CPU    0: hi:  186, btch:  31 usd:  50
Jan  9 12:06:33 twin kernel: CPU    1: hi:  186, btch:  31 usd: 222
Jan  9 12:06:33 twin kernel: active_anon:8855 inactive_anon:14090
isolated_anon:0
Jan  9 12:06:33 twin kernel: active_file:916356 inactive_file:2991941
isolated_file:32
Jan  9 12:06:33 twin kernel: unevictable:1783 dirty:13950 writeback:0
unstable:0
Jan  9 12:06:33 twin kernel: free:41920 slab_reclaimable:75729
slab_unreclaimable:8399
Jan  9 12:06:33 twin kernel: mapped:4758 shmem:196 pagetables:839 bounce:0
Jan  9 12:06:33 twin kernel: free_cma:0
Jan  9 12:06:33 twin kernel: Node 0 DMA free:15360kB min:60kB low:72kB
high:88kB active_anon:0kB inactive_anon:0kB active_file:0kB
inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB
present:15984kB managed:15360kB mlocked:0kB dirty:0kB writeback:0kB
mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB
kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB
writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Jan  9 12:06:33 twin kernel: lowmem_reserve[]: 0 3390 15953 15953
Jan  9 12:06:33 twin kernel: Node 0 DMA32 free:72612kB min:14348kB
low:17932kB high:21520kB active_anon:4496kB inactive_anon:8456kB
active_file:740880kB inactive_file:2562448kB unevictable:1820kB
isolated(anon):0kB isolated(file):112kB present:3549456kB
managed:3473772kB mlocked:1820kB dirty:11400kB writeback:0kB
mapped:4012kB shmem:164kB slab_reclaimable:71368kB
slab_unreclaimable:6740kB kernel_stack:1152kB pagetables:536kB
unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:112
all_unreclaimable? no
Jan  9 12:06:33 twin kernel: lowmem_reserve[]: 0 0 12563 12563
Jan  9 12:06:33 twin kernel: Node 0 Normal free:79808kB min:53168kB
low:66460kB high:79752kB active_anon:30924kB inactive_anon:47904kB
active_file:2924544kB inactive_file:9405204kB unevictable:5312kB
isolated(anon):0kB isolated(file):0kB present:13096960kB
managed:12864588kB mlocked:5312kB dirty:44400kB writeback:0kB
mapped:15020kB shmem:620kB slab_reclaimable:231548kB
slab_unreclaimable:26856kB kernel_stack:2784kB pagetables:2820kB
unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
Jan  9 12:06:33 twin kernel: lowmem_reserve[]: 0 0 0 0
Jan  9 12:06:33 twin kernel: Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB
0*64kB 0*128kB 0*256kB 0*512kB 1*1024kB (U) 1*2048kB (R) 3*4096kB (M) =
15360kB
Jan  9 12:06:33 twin kernel: Node 0 DMA32: 18157*4kB (EM) 1*8kB (M)
0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB
= 72636kB
Jan  9 12:06:33 twin kernel: Node 0 Normal: 18897*4kB (M) 0*8kB 0*16kB
0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB (R) =
79684kB
Jan  9 12:06:33 twin kernel: Node 0 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=2048kB
Jan  9 12:06:33 twin kernel: 3910139 total pagecache pages
Jan  9 12:06:33 twin kernel: 92 pages in swap cache
Jan  9 12:06:33 twin kernel: Swap cache stats: add 822, delete 730, find
1864/1962
Jan  9 12:06:33 twin kernel: Free swap  = 2096004kB
Jan  9 12:06:33 twin kernel: Total swap = 2097148kB
Jan  9 12:06:33 twin kernel: 4165600 pages RAM
Jan  9 12:06:33 twin kernel: 0 pages HighMem/MovableOnly
Jan  9 12:06:33 twin kernel: 58093 pages reserved
Jan  9 12:06:33 twin kernel: ------------[ cut here ]------------
Jan  9 12:06:33 twin kernel: kernel BUG at fs/btrfs/relocation.c:242!
Jan  9 12:06:33 twin kernel: invalid opcode: 0000 [#1] PREEMPT SMP
Jan  9 12:06:33 twin kernel: Modules linked in: fuse af_packet bnep
bluetooth ipt_MASQUERADE xt_nat iptable_nat nf_nat_ipv4 nf_nat xt_limit
nf_log_ipv4 nf_log_common xt_LOG ipt_REJECT nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_conntrack nf_conntrack ip6table_filter
iptable_filter ip6_tables ip_tables x_tables snd_aloop vfat fat nls_utf8
cryptoloop x86_pkg_temp_thermal loop intel_powerclamp coretemp tun
intel_rapl ipv6 kvm_intel kvm cpufreq_stats uas fbcon usb_storage
bitblit softcursor font i915 rtl8192ce rtl_pci drm_kms_helper rtlwifi
drm rtl8192c_common evdev mac80211 cfbfillrect cfbimgblt cfg80211
cfbcopyarea lpc_ich i2c_i801 rfkill r8169 i2c_algo_bit mfd_core mii
i2c_core fan fb snd_hda_codec_hdmi thermal xhci_hcd fbdev intel_gtt
snd_hda_codec_realtek agpgart snd_hda_codec_generic battery button video
acpi_cpufreq backlight snd_hda_intel ehci_pci snd_hda_controller
ehci_hcd snd_hda_codec usbcore snd_hwdep usb_common processor snd_pcm
thermal_sys hwmon rtc_cmos snd_timer snd shpchp soundcore [last
unloaded: microcode]
Jan  9 12:06:33 twin kernel: CPU: 1 PID: 3188 Comm: btrfs Not tainted
3.17.7-gentoo #2
Jan  9 12:06:33 twin kernel: Hardware name: Shuttle Inc. DS47D/FS47D,
BIOS 1.00 04/10/2013
Jan  9 12:06:33 twin kernel: task: ffff8800d53dabd0 ti: ffff8800057f4000
task.ti: ffff8800057f4000
Jan  9 12:06:33 twin kernel: RIP: 0010:[<ffffffff81363181>]
[<ffffffff81363181>] relocate_block_group+0x661/0x670
Jan  9 12:06:33 twin kernel: RSP: 0018:ffff8800057f7b10  EFLAGS: 00010202
Jan  9 12:06:33 twin kernel: RAX: ffff880404f318f8 RBX: ffff880404f31908
RCX: ffff8801b6fe2640
Jan  9 12:06:33 twin kernel: RDX: 0000000000000001 RSI: ffff880404f318e8
RDI: 0000000000000286
Jan  9 12:06:33 twin kernel: RBP: ffff8802439d1260 R08: 0000000000000000
R09: 0000000000000000
Jan  9 12:06:33 twin kernel: R10: ffff880136fe2640 R11: ffff8800021639c0
R12: ffff880404f318e8
Jan  9 12:06:33 twin kernel: R13: 00000000fffffff4 R14: ffff880404f31800
R15: 00000000fffffff4
Jan  9 12:06:33 twin kernel: FS:  00007fa633045b40(0000)
GS:ffff88041e300000(0000) knlGS:0000000000000000
Jan  9 12:06:33 twin kernel: CS:  0010 DS: 0000 ES: 0000 CR0:
0000000080050033
Jan  9 12:06:33 twin kernel: CR2: 00000000012ee18c CR3: 0000000407012000
CR4: 00000000000407e0
Jan  9 12:06:33 twin kernel: Stack:
Jan  9 12:06:33 twin kernel: ffff880404f31820 0000000000000102
00000000ffffffff 0000000000000000
Jan  9 12:06:33 twin kernel: ffff880114d9c848 00ff880114d9c600
a9000000055d5480 0000000000000001
Jan  9 12:06:33 twin kernel: ffff880404f31800 0000000000000000
ffff880404c2f800 ffff880114d9c580
Jan  9 12:06:33 twin kernel: Call Trace:
Jan  9 12:06:33 twin kernel: [<ffffffff81363347>] ?
btrfs_relocate_block_group+0x1b7/0x2c0
Jan  9 12:06:33 twin kernel: [<ffffffff8133a028>] ?
btrfs_relocate_chunk.isra.31+0x58/0x6a0
Jan  9 12:06:33 twin kernel: [<ffffffff812eea71>] ?
btrfs_set_path_blocking+0x31/0x70
Jan  9 12:06:33 twin kernel: [<ffffffff812f3ecd>] ?
btrfs_search_slot+0x4dd/0xae0
Jan  9 12:06:33 twin kernel: [<ffffffff81336478>] ?
read_extent_buffer+0xc8/0x120
Jan  9 12:06:33 twin kernel: [<ffffffff8132ca20>] ?
btrfs_get_token_64+0x50/0xe0
Jan  9 12:06:33 twin kernel: [<ffffffff81335451>] ?
release_extent_buffer+0x21/0xc0
Jan  9 12:06:33 twin kernel: [<ffffffff8133d07e>] ?
btrfs_balance+0x82e/0xe20
Jan  9 12:06:33 twin kernel: [<ffffffff813438ef>] ?
btrfs_ioctl_balance+0x14f/0x340
Jan  9 12:06:33 twin kernel: [<ffffffff81348cfc>] ? btrfs_ioctl+0x58c/0x2b10
Jan  9 12:06:33 twin kernel: [<ffffffff811ba90e>] ?
mem_cgroup_commit_charge+0x5e/0xa0
Jan  9 12:06:33 twin kernel: [<ffffffff81188798>] ?
handle_mm_fault+0x9a8/0xe90
Jan  9 12:06:33 twin kernel: [<ffffffff81036e58>] ?
__do_page_fault+0x1b8/0x450
Jan  9 12:06:33 twin kernel: [<ffffffff8118b9f1>] ? vma_link+0xb1/0xc0
Jan  9 12:06:33 twin kernel: [<ffffffff811cfda7>] ? do_vfs_ioctl+0x2d7/0x4b0
Jan  9 12:06:33 twin kernel: [<ffffffff811cfff9>] ? SyS_ioctl+0x79/0x90
Jan  9 12:06:33 twin kernel: [<ffffffff816b7948>] ? page_fault+0x28/0x30
Jan  9 12:06:33 twin kernel: [<ffffffff816b60ad>] ?
system_call_fastpath+0x1a/0x1f
Jan  9 12:06:33 twin kernel: Code: 8e fc ff ff 66 0f 1f 44 00 00 49 89
dc e9 e8 fe ff ff 45 31 ff 49 89 dc e9 dd fe ff ff 0f 0b 0f 0b 41 89 c5
e9 51 fc ff ff 0f 0b <0f> 0b 0f 0b 0f 0b 0f 0b 0f 1f 80 00 00 00 00 41
57 41 56 41 55
Jan  9 12:06:33 twin kernel: RIP  [<ffffffff81363181>]
relocate_block_group+0x661/0x670
Jan  9 12:06:33 twin kernel: RSP <ffff8800057f7b10>
Jan  9 12:06:33 twin kernel: ---[ end trace eabc51a5837da913 ]---

Re: Segfault in "btrfs balance start" due to kernel page allocation failure

[Duncan]

Remy Blank posted on Fri, 09 Jan 2015 12:19:23 +0100 as excerpted:

> I have a btrfs filesystem that shows the following errors. This happens
> either when writing to the FS or when snapshotting, I'm not sure (this
> FS holds my backup, and I write to it with rsync and snapshot
> afterward).
> 
> Jan  8 13:54:33 twin kernel: BTRFS error (device dm-2):
> error inheriting props for ino 3828 (root 317): -28
> Jan  8 13:54:38 twin kernel: BTRFS error (device dm-2):
> error inheriting props for ino 17939 (root 317): -28

Just another user here, posting only to say I don't recall seeing a props 
inheritance error like that posted before.  Could be a new and 
interesting bug.

Also, when you post errors, please post kernel and btrfs-progs versions.  
I see from the trace that your kernel version is 3.17.7 so you're 
reasonably current there, but of course that doesn't give the userspace 
version.

And finally just a practical note.  Over time I've noticed that rsync 
seems to be involved in quite a few posted bugs, most of which have of 
course been fixed by now.  Rsync apparently stresses btrfs in ways few 
other tasks do, thus triggering more than its share of bugs that most 
other things don't tend to tickle.  I'm a gentooer myself, with (among 
other things) the main package tree rsynced to btrfs, and have seemed to 
escape these issues, but (1) all my btrfs are on SSD and thus likely 
escape some of the race conditions that trigger on spinning rust, and (2) 
I'm a strong believer in not putting all my data eggs in the same 
filesystem basket so I partition heavily, and all my partitions are 
relatively small (biggest btrfs 24 GiB, actually the gentoo tree, 
sources, and binpkgs partition).  Additionally, I prefer backups to 
identically sized partitions over snapshots (which are nice but if the 
filesystem has problems it takes all the snapshots with it), and thus 
don't tend to use the btrfs snapshots feature.  I suspect that has 
something to do with my relative scarcity of triggered btrfs issues, here.

So just be aware that rsync /does/ seem to stress btrfs more than most 
tasks, and try to plan/behave accordingly, perhaps avoiding rsync when 
possible, or keeping additional backups in case, and/or choosing 
something other than btrfs for at least one level of backups, etc.  (FWIW 
my non-btrfs level of backups here is reiserfs, the filesystem I used for 
years previously, which at least since the introduction of data=ordered 
back around kernel 2.6.16 or so, has done very well for me even thru 
hardware issues, etc.  Others on the list recommend xfs, but few seem 
particularly impressed with ext*, for whatever it's worth.  That last 
could simply be a biased sample, tho, as people involved in btrfs are I 
suspect less likely to be content with the traditional ext* status quo 
than the average Linuxer, but whatever the reason, cause or bias, ext* 
seems to get short shrift on this list.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: Segfault in "btrfs balance start" due to kernel page allocation failure

[Remy Blank]

Duncan wrote on 2015-01-09 23:43:
> Also, when you post errors, please post kernel and btrfs-progs versions.  
> I see from the trace that your kernel version is 3.17.7 so you're 
> reasonably current there, but of course that doesn't give the userspace 
> version.

I did mention 3.17.7, but I forgot to say it was the kernel :) Userspace
is 3.18.

> And finally just a practical note.  Over time I've noticed that rsync 
> seems to be involved in quite a few posted bugs, most of which have of 
> course been fixed by now.  Rsync apparently stresses btrfs in ways few 
> other tasks do, thus triggering more than its share of bugs that most 
> other things don't tend to tickle. 

Maybe it would be worth adding some tests using rsync to the test suite
(I assume there is one)?

> I'm a gentooer myself, with (among 
> other things) the main package tree rsynced to btrfs, and have seemed to 
> escape these issues, but (1) all my btrfs are on SSD and thus likely 
> escape some of the race conditions that trigger on spinning rust, and (2) 
> I'm a strong believer in not putting all my data eggs in the same 
> filesystem basket

Yeah, that's definitely very good advice. I'm currently using
rdiff-backup for my backups, but it's been unsupported for years and I
was looking for a good replacement. Btrfs snapshots seemed like a very
good candidate, so I converted my 4 machines to btrfs and set up hourly
snapshots on the laptops and rsync/snapshot backups on the servers.
While doing this, I was hit with several errors, some of which I could
fix and some that I don't know what to do about. This is one of them.

Having kernel errors pop up under totally normal conditions, when the
only load is periodically copying stuff over and snapshotting, scared me
enough that I'm now converting back to ext4 (I was on ext3 before, but
apparently ext4 is now safe enough since the fsync fiasco was resolved).
I never had any issues with ext*, but of course that's only a single
data point.

> so I partition heavily, and all my partitions are 
> relatively small (biggest btrfs 24 GiB, actually the gentoo tree, 
> sources, and binpkgs partition).  Additionally, I prefer backups to 
> identically sized partitions over snapshots (which are nice but if the 
> filesystem has problems it takes all the snapshots with it), and thus 
> don't tend to use the btrfs snapshots feature.  I suspect that has 
> something to do with my relative scarcity of triggered btrfs issues, here.

I'll continue using btrfs but on loopback-mounted files stored on ext4,
and play some more with snapshot-based backups (while still doing
backups with rdiff-backup, so I can afford to lose the containers). I'll
check back in a year or two, hopefully btrfs will have gained more
stability by then. The feature set is certainly awesome, so I'm looking
forward to being able to use it.

> So just be aware that rsync /does/ seem to stress btrfs more than most 
> tasks, and try to plan/behave accordingly, perhaps avoiding rsync when 
> possible, or keeping additional backups in case, and/or choosing 
> something other than btrfs for at least one level of backups, etc.

Having to restrict what kinds of tools I can use on a filesystem is a
serious limitation, so for now I'm not going to use btrfs for anything
that isn't completely disposable.

-- Remy

Re: Segfault in "btrfs balance start" due to kernel page allocation failure

[Duncan]

Remy Blank posted on Sat, 10 Jan 2015 01:41:31 +0100 as excerpted:

> Maybe it would be worth adding some tests using rsync to the test suite
> (I assume there is one)?

Yes.  xfs-tests (which isn't just for xfs any more, ext4, btrfs, and 
possibly others, use it too).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: Segfault in "btrfs balance start" due to kernel page allocation failure

[Duncan]

Remy Blank posted on Sat, 10 Jan 2015 01:41:31 +0100 as excerpted:

> I'll check back in a year or two, hopefully btrfs will have gained more
> stability by then. The feature set is certainly awesome, so I'm looking
> forward to being able to use it.

Yes.  Despite the removal of the experimental warnings, btrfs isn't yet 
(entirely) stable, and the general sysadmin adage that if if you don't 
have backups, you don't /actually/ care about losing the data no matter 
what you /claim/, and that backups that aren't tested as actually usable 
aren't backups at all, applies in an even stronger way to btrfs than it 
will to more mature and stable filesystems.  And people not prepared to 
deal with that really should choose something more mature and stable at 
this point.

But at the same time, btrfs is maturing quite fast now, and is vastly 
more stable and mature now that it was a year ago, so it's coming along.  
I'd guess the code should be getting close to what I'd call "stable" in a 
year or so and may in fact be very close to it with 3.19, but I'd not be 
comfortable actually calling it stable until nearly a year (which happens 
to be roughly five kernel series...) later, with no serious issues in the 
intervening time.  Thus, if I think the code will be basically stable 
within a year as I think is reasonable, it'd be a year after that before 
I'd be really comfortable /calling/ it stable, which puts it about two 
years out, just as you said.

Tho of course major distros are beginning to make it the default even now 
(OpenSuSE being the first, I believe) so it's already stable /enough/ for 
them, and as you mention, more conservative users are only now beginning 
to consider ext4 stable, and for them, btrfs stability may yet be five 
years out...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman