spl/zfs-0.6.0-rc4

Gordan Bobic gordan.bobic at gmail.com
Fri May 6 13:27:17 EDT 2011


On 05/06/2011 05:40 PM, Brian Behlendorf wrote:
> Please let us know how it goes, you shouldn't see a crash.  However,
> even if you you can very likely recover without resorting to backups by
> setting the 'zfs_no_scrub_io' module option.  This will prevent the
> actual scrub IO from being issued which gives you a chance to import the
> pool and manually disable the scrub.

It's not looking good so far:

y  6 17:53:05 raiden kernel: VERIFY(sa_lookup(ITOZ(ip)->z_sa_hdl, 
SA_ZPL_RDEV(zsb), &rdev, sizeof (rdev)) == 0) failed
May  6 17:53:05 raiden kernel: SPLError: 
2424:0:(zfs_znode.c:305:zfs_inode_set_ops()) SPL PANIC
May  6 17:53:05 raiden kernel: SPL: Showing stack for process 2424
May  6 17:53:05 raiden kernel: Pid: 2424, comm: nfsd Tainted: P 
   ----------------  2.6.32-71.24.1.el6.x86_64 #1
May  6 17:53:05 raiden kernel: Call Trace:
May  6 17:53:05 raiden kernel: [<ffffffffa031b5b7>] 
spl_debug_dumpstack+0x27/0x40 [spl]
May  6 17:53:05 raiden kernel: [<ffffffffa031ccd1>] 
spl_debug_bug+0x81/0xd0 [spl]
May  6 17:53:05 raiden kernel: [<ffffffffa0478d2e>] 
zfs_znode_alloc+0x4ae/0x4c0 [zfs]
May  6 17:53:05 raiden kernel: [<ffffffffa03fa825>] ? 
dmu_object_info_from_dnode+0x115/0x190 [zfs]
May  6 17:53:05 raiden kernel: [<ffffffffa0478e80>] zfs_zget+0x140/0x1d0 
[zfs]
May  6 17:53:05 raiden kernel: [<ffffffffa045c152>] 
zfs_dirent_lock+0x462/0x520 [zfs]
May  6 17:53:05 raiden kernel: [<ffffffffa045c3ed>] 
zfs_dirlook+0x6d/0x1d0 [zfs]
May  6 17:53:05 raiden kernel: [<ffffffff812001f6>] ? 
security_task_setgroups+0x16/0x20
May  6 17:53:05 raiden kernel: [<ffffffffa04734d2>] 
zfs_lookup+0x302/0x350 [zfs]
May  6 17:53:05 raiden kernel: [<ffffffffa0485687>] zpl_lookup+0x57/0xc0 
[zfs]
May  6 17:53:05 raiden kernel: [<ffffffff8117b312>] 
__lookup_hash+0x102/0x160
May  6 17:53:05 raiden kernel: [<ffffffff8117b5e4>] 
lookup_one_len+0xb4/0x110
May  6 17:53:05 raiden kernel: [<ffffffffa0678b6d>] 
nfsd_lookup_dentry+0x10d/0x500 [nfsd]
May  6 17:53:05 raiden kernel: [<ffffffffa0678f93>] 
nfsd_lookup+0x33/0xd0 [nfsd]
May  6 17:53:05 raiden kernel: [<ffffffffa0681612>] 
nfsd3_proc_lookup+0x92/0xf0 [nfsd]
May  6 17:53:05 raiden kernel: [<ffffffffa067243e>] 
nfsd_dispatch+0xfe/0x250 [nfsd]
May  6 17:53:05 raiden kernel: [<ffffffffa05f7544>] 
svc_process_common+0x344/0x610 [sunrpc]
May  6 17:53:05 raiden kernel: [<ffffffff8105c540>] ? 
default_wake_function+0x0/0x20
May  6 17:53:05 raiden kernel: [<ffffffffa05f7b50>] 
svc_process+0x110/0x150 [sunrpc]
May  6 17:53:05 raiden kernel: [<ffffffffa0672b62>] nfsd+0xc2/0x160 [nfsd]
May  6 17:53:05 raiden kernel: [<ffffffffa0672aa0>] ? nfsd+0x0/0x160 [nfsd]
May  6 17:53:05 raiden kernel: [<ffffffff81091ae6>] kthread+0x96/0xa0
May  6 17:53:05 raiden kernel: [<ffffffff810141ca>] child_rip+0xa/0x20
May  6 17:53:05 raiden kernel: [<ffffffff81091a50>] ? kthread+0x0/0xa0
May  6 17:53:05 raiden kernel: [<ffffffff810141c0>] ? child_rip+0x0/0x20
May  6 17:53:05 raiden kernel: SPL: Dumping log to 
/tmp/spl-log.1304700785.2424

Mentioned dumped log is attached.

This happens consistently when files are accessed over NFS (my /home is 
on ZFS and exported via NFS) and it crashes things to the point where 
the fs won't umount and I have to reboot the server.

The KQ implementation does not exhibit this issue so I have rolled back 
to that for now.

Gordan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: spl-log.1304700785.2424
Type: application/octet-stream
Size: 88 bytes
Desc: not available
URL: <http://list.zfsonlinux.org/pipermail/zfs-discuss/attachments/20110506/bda57089/attachment.obj>


More information about the zfs-discuss mailing list