(from spl/issues/389) -- SPLError: 26788:0:(range_tree.c:172:range_tree_add()) SPL PANIC

[TioNisla]

"rsync -PSAXrltgoD --del" from remote host caused 'SPLError'

full text here: https://gist.github.com/anonymous/39e252399acb6912a16e

P.S.
After removal of storage/samba filesystem, when importing a pool there is this problem, it isn't possible to export or remove a pool: all zfs/zpool related commands just hangs.

[yeoldegrove]

I can confirm this.
It happens to my system when importing a specific zpool.
After this exception the system itself is still responding, but the pool does not get imported.

My OS happened to crash a few times because of a broken RAM-module.
After removing the broken hardware a "zpool import" is still not possible!
Tried several up-to-date OS (arch, debian, ubuntu) with official zfs packages.

Any chance this gets fixed? Can I contribute?

[behlendorf]

Could you try importing the pool using the latest source from github. There have been several fixes in this area. You can find directions for how to build the latest source at zfsonlinux.org.

[yeoldegrove]

Build spl,zfs.zfs-utils on my arch box checking out latest github source.
No change.

Details: https://gist.github.com/yeoldegrove/b1d5a83587dbce437c52

[behlendorf]

@yeoldegrove the failure you're seeing indicates that somehow the same address is being freed twice. Can you please rebuild your zfs source with the following patch applied and set the zfs_recover=1 module option. Assuming this is the only problem it should allow you to import the pool and log the offending address so we can sanity check it.

diff --git a/module/zfs/range_tree.c b/module/zfs/range_tree.c
index 4643d26..b5c9222 100644
--- a/module/zfs/range_tree.c
+++ b/module/zfs/range_tree.c
@@ -175,7 +175,7 @@ range_tree_add(void *arg, uint64_t start, uint64_t size)
        rsearch.rs_end = end;
        rs = avl_find(&rt->rt_root, &rsearch, &where);

-       if (rs != NULL && rs->rs_start <= start && rs->rs_end >= end) {
+       if (rs != NULL) {
                zfs_panic_recover("zfs: allocating allocated segment"
                    "(offset=%llu size=%llu)\n",
                    (longlong_t)start, (longlong_t)size);

[yeoldegrove]

Works like a charm now.
Only messages are...

root@host ~ # dmesg | grep -Ei 'SPL|ZFS'
[ 9.034938] SPL: Loaded module v0.6.3-44_g46c9367
[ 9.062044] ZFS: Loaded module v0.6.3-133_g9635861, ZFS pool version 5000, ZFS filesystem version 5
[ 59.407576] SPL: using hostid 0x640a2900
[ 86.933817] SPLError: 2287:0:(spl-err.c:88:vcmn_err()) WARNING: zfs: allocating allocated segment(offset=870105374720 size=67117056)

The pool now imports and exports in seconds, even across reboots.

I'll go back to the usual upstream code and will report if it still works later.

[yeoldegrove]

After running the regular packages from arch demz-repo-core repo for two days now, everything seems to run fine.

[behlendorf]

A patch for ignoring bad DVAs on blocks which are being freed when zfs_recover=1 is set has been merged. This doesn't get to the root cause of how this could happen but it does provide as more convenient way to recover which has been damaged in this way.