SPLError: <PID>:0:(zfs_znode.c:330:zfs_inode_set_ops()) SPL PANIC on 0.6.0.86-rc12

[alexfv]

I use ZoL from Ubuntu stable repository on Debian x86_64, my ZoL version is 0.6.0.86-rc12,
but the pool was created on ZoL 0.6.0.56.

When I try to browse files in a mouted volume, I get "kernel panic" with message
kernel:[ 1800.373739] SPLError: 2625:0:(zfs_znode.c:330:zfs_inode_set_ops()) SPL PANIC

Although I can browse top-level directories (without files) at the root of volume.

Corresponding to issue openzfs/zfs#709 I have disabled xattrs (zfs set xattr=no), made scrub, but files in the volume are still unreadable.

#uname -a
Linux hostname 3.4-trunk-amd64 #1 SMP Tue Jun 26 17:23:03 UTC 2012 x86_64 GNU/Linux
#dmesg | grep ZFS
[   22.793789] ZFS: Loaded module v0.6.0.86-rc12, ZFS pool version 28, ZFS filesystem version 5
#zpool status | grep scan
scan: scrub repaired 0 in 1h1m with 0 errors on Thu Nov 22 13:30:13 2012


[ 1800.370172] ZFS: Invalid mode: 0xd769
[ 1800.370180] VERIFY(0) failed
[ 1800.373739] SPLError: 2625:0:(zfs_znode.c:330:zfs_inode_set_ops()) SPL PANIC
[ 1800.379674] SPL: Showing stack for process 2625
[ 1800.379683] Pid: 2625, comm: smbd Tainted: P           O 3.4-trunk-amd64 #1
[ 1800.379688] Call Trace:
[ 1800.379715]  [<ffffffffa027555b>] ? spl_debug_dumpstack+0x24/0x2a [spl]
[ 1800.379729]  [<ffffffffa0276500>] ? spl_debug_bug+0x7f/0xc8 [spl]
[ 1800.379789]  [<ffffffffa05835a8>] ? zfs_znode_alloc+0x415/0x4c2 [zfs]
[ 1800.379841]  [<ffffffffa05853b9>] ? zfs_zget+0x19b/0x1cf [zfs]
[ 1800.379893]  [<ffffffffa056b785>] ? zfs_dirent_lock+0x414/0x445 [zfs]
[ 1800.379945]  [<ffffffffa056b976>] ? zfs_dirlook+0x1c0/0x229 [zfs]
[ 1800.379998]  [<ffffffffa05690fb>] ? zfs_zaccess+0x128/0x1cb [zfs]
[ 1800.380008]  [<ffffffff8110d4fc>] ? dentry_cmp+0x2c/0x76
[ 1800.380019]  [<ffffffff81057d77>] ? should_resched+0x5/0x23
[ 1800.380068]  [<ffffffffa05804af>] ? zfs_lookup+0x270/0x2b8 [zfs]
[ 1800.380115]  [<ffffffffa058fc9e>] ? zpl_lookup+0x47/0x80 [zfs]
[ 1800.380124]  [<ffffffff811063f6>] ? __lookup_hash+0xa3/0xcb
[ 1800.380131]  [<ffffffff81106e69>] ? walk_component+0x2a2/0x3c7
[ 1800.380140]  [<ffffffff81107b83>] ? path_lookupat+0x7c/0x2a9
[ 1800.380147]  [<ffffffff81107dcc>] ? do_path_lookup+0x1c/0x87
[ 1800.380155]  [<ffffffff8110987c>] ? user_path_at_empty+0x47/0x7b
[ 1800.380164]  [<ffffffff81119552>] ? inode_to_bdi+0x1d/0x39
[ 1800.380172]  [<ffffffff8111adfb>] ? __mark_inode_dirty+0x157/0x17d
[ 1800.380180]  [<ffffffff81101878>] ? vfs_fstatat+0x32/0x60
[ 1800.380188]  [<ffffffff8110b847>] ? vfs_readdir+0x92/0xa3
[ 1800.380195]  [<ffffffff811019a2>] ? sys_newstat+0x12/0x2b
[ 1800.380203]  [<ffffffff8110badc>] ? sys_getdents+0xbf/0xcd
[ 1800.380213]  [<ffffffff8135edf9>] ? system_call_fastpath+0x16/0x1b
[ 1800.380304] SPL: Dumping log to /tmp/spl-log.1353585074.2625

[behlendorf]

If you were running with xattr=sa with an older version of ZoL simply updating to rc12 isn't going to be enough to fix it. The issue is on disk and the checksum is correct so the scrub won't catch it. You may be able to remove the file to prevent further panics, but if possible you should destroy and recreate the dataset from a backup. If the data's not easily replaceable we could probably fairly easily tweak ZoL to return an error here instead of making it fatal.

Oh, and this issue was fixed in rc11.