Description of problem: zfs-fuse crashes when attempting to do a large number of chmod operations on normal files Version-Release number of selected component (if applicable): zfs-fuse-0.7.0-10.fc18.x86_64 How reproducible: find /path/to/zfs/ -type f -print0 | xargs -0 --replace chmod -c a-w "{}" Actual results: zfs-fuse daemon crashes Expected results: File modes change Additional info: Program received signal SIGABRT, Aborted. [Switching to Thread 0x2aaaaf273700 (LWP 1779)] 0x0000003412435ba5 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:63 63 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (gdb) bt #0 0x0000003412435ba5 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:63 #1 0x0000003412437358 in __GI_abort () at abort.c:90 #2 0x0000000000408e7b in zfs_acl_xform (zp=zp@entry=0x2aaac2c91dd0, aclp=aclp@entry=0x2aaaaaefaa80, cr=cr@entry=0x2aaaaf272a00) at zfs-fuse/zfs_acl.c:721 #3 0x000000000040939e in zfs_aclset_common (zp=zp@entry=0x2aaac2c91dd0, aclp=0x2aaaaaefaa80, cr=cr@entry=0x2aaaaf272a00, tx=tx@entry=0x2aaab3ed2830) at zfs-fuse/zfs_acl.c:1081 #4 0x000000000041c07a in zfs_setattr (vp=0x2aaac41c87d0, vap=0x2aaaaf272a10, flags=0, cr=0x2aaaaf272a00, ct=<optimized out>) at zfs-fuse/zfs_vnops.c:2871 #5 0x000000000042209e in zfsfuse_setattr (req=req@entry=0x2aaad00048d0, ino=7, attr=0x2aaaaf272bb0, to_set=<optimized out>, fi=<optimized out>) at zfs-fuse/zfs_operations.c:1324 #6 0x0000000000422239 in zfsfuse_setattr_helper (req=0x2aaad00048d0, ino=<optimized out>, attr=<optimized out>, to_set=<optimized out>, fi=<optimized out>) at zfs-fuse/zfs_operations.c:1348 #7 0x00000031de816a6d in do_setattr (req=<optimized out>, nodeid=<optimized out>, inarg=<optimized out>) at fuse_lowlevel.c:1076 #8 0x00000031de817057 in fuse_ll_process_buf (data=0x2aab0800a9a0, buf=buf@entry=0x2aaaaf272de0, ch=<optimized out>) at fuse_lowlevel.c:2441 #9 0x00000031de817436 in fuse_ll_process (data=<optimized out>, buf=<optimized out>, len=<optimized out>, ch=<optimized out>) at fuse_lowlevel.c:2463 #10 0x000000000041e64e in zfsfuse_listener_loop (arg=<optimized out>) at zfs-fuse/fuse_listener.c:290 #11 0x0000003412c07d15 in start_thread (arg=0x2aaaaf273700) at pthread_create.c:308 #12 0x00000034124f246d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114
I just tried this with a tree containing 1,530 files totalling 41M and zfs-fuse stayed up. How many files are you chmoding when your crashes?
Usually it dies after a few dozen on this one pool. This pool has been recently mounted on another machine using the in-kernel ZFS implementation at http://zfsonlinux.org/ but was NOT upgraded. It was then exported and re-imported on the system running zfs-fuse. I'm wondering if zfs-fuse is not tolerant of an attribute change that was added by the in-kernel version.
Possibly. Do you know what change that might be?
I don't have the pool anymore, but IIRC, it was mostly just chmod/chown on a pool moved between zfs-fuse and in-kernel zfs. It is possible that compression and/or dedup was enabled on the pool. Thanks, Doug
Well, if in the future you can reproduce this or at least provide a complete recipe to do so, by all means re-open. I'll keep banging at it if I get some spare storage.