{"push_id":937398885,"size":10,"distinct_size":10,"ref":"refs/heads/master","head":"bc89ac8479c0b265c539b579fda2bef1997d423c","before":"d21f279a94994f65e6bdcbbca9fd2eb552a0d604","commits":[{"sha":"0720116d4dd7a62d2097863fc4c32c3cbd11aefa","author":{"email":"32d50ad1e384dcb9a5bf7e40fa470df5dabaf348@llnl.gov","name":"Brian Behlendorf"},"message":"Add zfs_object_mutex_size module option\n\nAdd a zfs_object_mutex_size module option to facilitate resizing the\nthe per-dataset znode mutex array.  Increasing this value may help\nmake the deadlock described in #4106 less common, but this is not a\nproper fix.  This patch is primarily to aid debugging and analysis.\n\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nSigned-off-by: Tim Chase <tim@chase2k.com>\nIssue #4106","distinct":true,"url":"https://api.github.com/repos/zfsonlinux/zfs/commits/0720116d4dd7a62d2097863fc4c32c3cbd11aefa"},{"sha":"c96c36fa22ab97f6b3025b356bfca8d9e030d002","author":{"email":"32d50ad1e384dcb9a5bf7e40fa470df5dabaf348@llnl.gov","name":"Brian Behlendorf"},"message":"Fix zsb->z_hold_mtx deadlock\n\nThe zfs_znode_hold_enter() / zfs_znode_hold_exit() functions are used to\nserialize access to a znode and its SA buffer while the object is being\ncreated or destroyed.  This kind of locking would normally reside in the\nznode itself but in this case that's impossible because the znode and SA\nbuffer may not yet exist.  Therefore the locking is handled externally\nwith an array of mutexs and AVLs trees which contain per-object locks.\n\nIn zfs_znode_hold_enter() a per-object lock is created as needed, inserted\nin to the correct AVL tree and finally the per-object lock is held.  In\nzfs_znode_hold_exit() the process is reversed.  The per-object lock is\nreleased, removed from the AVL tree and destroyed if there are no waiters.\n\nThis scheme has two important properties:\n\n1) No memory allocations are performed while holding one of the z_hold_locks.\n   This ensures evict(), which can be called from direct memory reclaim, will\n   never block waiting on a z_hold_locks which just happens to have hashed\n   to the same index.\n\n2) All locks used to serialize access to an object are per-object and never\n   shared.  This minimizes lock contention without creating a large number\n   of dedicated locks.\n\nOn the downside it does require znode_lock_t structures to be frequently\nallocated and freed.  However, because these are backed by a kmem cache\nand very short lived this cost is minimal.\n\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nIssue #4106","distinct":true,"url":"https://api.github.com/repos/zfsonlinux/zfs/commits/c96c36fa22ab97f6b3025b356bfca8d9e030d002"},{"sha":"b10695c8f1ce317cd24d99af7998741a35a5ce48","author":{"email":"0e6295540f566aad05a0dc0d8facf057c9f8e443@clusterhq.com","name":"Richard Yao"},"message":"Remove fastwrite mutex\n\nThe fast write mutex is intended to protect accounting, but it is\nredundant because all accounting is performed through atomic operations.\nIt also serializes all metaslab IO behind a mutex, which introduces a\ntheoretical scaling regression that the Illumos developers did not like\nwhen we showed this to them. Removing it makes the selection of the\nmetaslab_group lock free as it is on Illumos. The selection is not quite\nthe same without the lock because the loop races with IO completions,\nbut any imbalances caused by this are likely to be corrected by\nsubsequent metaslab group selections.\n\nSigned-off-by: Richard Yao <ryao@gentoo.org>\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nCloses #3643","distinct":true,"url":"https://api.github.com/repos/zfsonlinux/zfs/commits/b10695c8f1ce317cd24d99af7998741a35a5ce48"},{"sha":"546f38433a870a2cf9907c6c61daad22a289fe39","author":{"email":"c64f7f1e6060e851acfe9b5bdea00a17cb81871c@gentoo.org","name":"Richard Yao"},"message":"SET_ERROR should print strings\n\nWhen debugging with tracepoints, we see string pointers:\n\nzfs  3017 [006]  8878.728915: zfs:zfs_set__error: ffffffffa0eec3fc:3013:ffffffffa0ebcd60(): error 0x2\n        ffffffffa0e1ca43 spa_open_common (/lib/modules/3.12.21-gentoo-r1/extra/zfs/zfs.ko)\n        ffffffffa0e1cbe3 spa_open (/lib/modules/3.12.21-gentoo-r1/extra/zfs/zfs.ko)\n        ffffffffa0e6f6ef zfs_ioc_stable (/lib/modules/3.12.21-gentoo-r1/extra/zfs/zfs.ko)\n        ffffffffa0e6f2a9 zfsdev_ioctl (/lib/modules/3.12.21-gentoo-r1/extra/zfs/zfs.ko)\n        ffffffff811909dd do_vfs_ioctl ([kernel.kallsyms])\n        ffffffff81190c41 sys_ioctl ([kernel.kallsyms])\n        ffffffff8156e2e9 system_call_fastpath ([kernel.kallsyms])\n            7ff7d8be69c7 __GI___ioctl (/lib64/libc-2.19.so)\n            7ff7d90cac53 lzc_ioctl.constprop.3 (/lib64/libzfs_core.so.1.0.0)\n        636f695f637a6c00 [unknown] ([unknown])\n\nPrinting the actual strings is more convenient:\n\nzfs  3461 [001] 10599.847692: zfs:zfs_set__error: spa.c:3013:spa_open_common(): error 0x2\n        ffffffffa116ba43 spa_open_common (/lib/modules/3.12.21-gentoo-r1/extra/zfs/zfs.ko)\n        ffffffffa116bbe3 spa_open (/lib/modules/3.12.21-gentoo-r1/extra/zfs/zfs.ko)\n        ffffffffa11be8df zfs_ioc_stable (/lib/modules/3.12.21-gentoo-r1/extra/zfs/zfs.ko)\n        ffffffffa11be499 zfsdev_ioctl (/lib/modules/3.12.21-gentoo-r1/extra/zfs/zfs.ko)\n        ffffffff811909dd do_vfs_ioctl ([kernel.kallsyms])\n        ffffffff81190c41 sys_ioctl ([kernel.kallsyms])\n        ffffffff8156e2e9 system_call_fastpath ([kernel.kallsyms])\n            7f11b843c9c7 __GI___ioctl (/lib64/libc-2.19.so)\n            7f11b8920c53 lzc_ioctl.constprop.3 (/lib64/libzfs_core.so.1.0.0)\n        636f695f637a6c00 [unknown] ([unknown])\n\nA few other tracepoints have strings as well, so switch to printing\nthe actual string values at the same time.\n\nSigned-off-by: Richard Yao <ryao@gentoo.org>\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nCloses #4212","distinct":true,"url":"https://api.github.com/repos/zfsonlinux/zfs/commits/546f38433a870a2cf9907c6c61daad22a289fe39"},{"sha":"21f604d4607e9e76a632438ee9274d3a8ce3180d","author":{"email":"0d8609c212ab3f9760c0051ba4e9c6b9d92c1063@osnexus.com","name":"Chunwei Chen"},"message":"Prevent duplicated xattr between SA and dir\n\nWhen replacing an xattr would cause overflowing in SA, we would fallback\nto xattr dir. However, current implementation don't clear the one in SA,\nso we would end up with duplicated SA.\n\nFor example, running the following script on an xattr=sa filesystem\nwould cause duplicated \"user.1\".\n\n-- dup_xattr.sh begin --\nrandbase64()\n{\n        dd if=/dev/urandom bs=1 count=$1 2>/dev/null | openssl enc -a -A\n}\n\nfile=$1\ntouch $file\nsetfattr -h -n user.1 -v `randbase64 5000` $file\nsetfattr -h -n user.2 -v `randbase64 20000` $file\nsetfattr -h -n user.3 -v `randbase64 20000` $file\nsetfattr -h -n user.1 -v `randbase64 20000` $file\ngetfattr -m. -d $file\n-- dup_xattr.sh end --\n\nAlso, when a filesystem is switch from xattr=sa to xattr=on, it will\nnever modify those in SA. This would cause strange behavior like, you\ncannot delete an xattr, or setxattr would cause duplicate and the result\nwould not match when you getxattr.\n\nFor example, the following shell sequence.\n\n-- shell begin --\n$ sudo zfs set xattr=sa pp/fs0\n$ touch zzz\n$ setfattr -n user.test -v asdf zzz\n$ sudo zfs set xattr=on pp/fs0\n$ setfattr -x user.test zzz\nsetfattr: zzz: No such attribute\n$ getfattr -d zzz\nuser.test=\"asdf\"\n$ setfattr -n user.test -v zxcv zzz\n$ getfattr -d zzz\nuser.test=\"asdf\"\nuser.test=\"asdf\"\n-- shell end --\n\nWe fix this behavior, by first finding where the xattr resides before\nsetxattr. Then, after we successfully updated the xattr in one location,\nwe will clear the other location. Note that, because update and clear\nare not in single tx, we could still end up with duplicated xattr. But\nby doing setxattr again, it can be fixed.\n\nSigned-off-by: Chunwei Chen <david.chen@osnexus.com>\nCloses #3472\nCloses #4153","distinct":true,"url":"https://api.github.com/repos/zfsonlinux/zfs/commits/21f604d4607e9e76a632438ee9274d3a8ce3180d"},{"sha":"59d4c71cca3bd6a1f122129ebb001089f903f182","author":{"email":"2d2f4bb63446d288f5381ac30a666099a0e77071@delphix.com","name":"George Wilson"},"message":"Illumos 3557, 3558, 3559, 3560\n\n3557 dumpvp_size is not updated correctly when a dump zvol's size is changed\n3558 setting the volsize on a dump device does not return back ENOSPC\n3559 setting a volsize larger than the space available sometimes succeeds\n3560 dumpadm should be able to remove a dump device\nReviewed by: Adam Leventhal <ahl@delphix.com>\nReviewed by: Matthew Ahrens <mahrens@delphix.com>\nReviewed by: Christopher Siden <christopher.siden@delphix.com>\nApproved by: Albert Lee <trisk@nexenta.com>\n\nReferences:\n  https://www.illumos.org/issues/3559\n  https://github.com/illumos/illumos-gate/commit/c61ea56\n\nPorting notes:\n- Internal zvol.c changes not applied due to implementation differences.\n  The external interface and behavior was already consistent with the\n  latest upstream code.\n- Retired 2.6.28 HAVE_CHECK_DISK_SIZE_CHANGE configure check.  All\n  supported kernels (2.6.32 and newer) provide this interface.\n\nPorted-by: Brian Behlendorf <behlendorf1@llnl.gov>\nCloses #4217","distinct":true,"url":"https://api.github.com/repos/zfsonlinux/zfs/commits/59d4c71cca3bd6a1f122129ebb001089f903f182"},{"sha":"82f6f6e654a51b47f9f2d642197852ced80487ee","author":{"email":"ba04a989f6209fba88685ad8caf63df30d525dc5@delphix.com","name":"Joe Stein"},"message":"Illumos 6298 - zfs_create_008_neg and zpool_create_023_neg\n\n6298 zfs_create_008_neg and zpool_create_023_neg need to be updated\nfor large block support\nReviewed by: Matthew Ahrens <mahrens@delphix.com>\nReviewed by: John Kennedy <john.kennedy@delphix.com>\nApproved by: Robert Mustacchi <rm@joyent.com>\n\nReferences:\n  https://www.illumos.org/issues/6298\n  https://github.com/illumos/illumos-gate/commit/e9316f7\n\nPorted-by: Brian Behlendorf <behlendorf1@llnl.gov>\nCloses #4217","distinct":true,"url":"https://api.github.com/repos/zfsonlinux/zfs/commits/82f6f6e654a51b47f9f2d642197852ced80487ee"},{"sha":"812e91a7e3abe59565462e4bb2a01724afddb042","author":{"email":"8d2898d7cb27797c18f60f841795fa450248b058@nexenta.com","name":"Marcel Telka"},"message":"Illumos 4039 - zfs_rename()/zfs_link() needs stronger test for XDEV\n\n4039 zfs_rename()/zfs_link() needs stronger test for XDEV\nReviewed by: Gordon Ross <gordon.ross@nexenta.com>\nReviewed by: Kevin Crowe <kevin.crowe@nexenta.com>\nReviewed by: Saso Kiselkov <skiselkov.ml@gmail.com>\nReviewed by: Matthew Ahrens <mahrens@delphix.com>\nApproved by: Dan McDonald <danmcd@nexenta.com>\n\nReferences:\n  https://www.illumos.org/issues/4039\n  https://github.com/illumos/illumos-gate/commit/18e6497\n\nPorting notes:\n- This check was updated in Linux in a similar fashion early on in\n  the port.  Therefore, this patch just reorders the function and\n  updates the comment so it flows the same way as the upstream code.\n\nPorted-by: Brian Behlendorf <behlendorf1@llnl.gov>\nCloses #4218","distinct":true,"url":"https://api.github.com/repos/zfsonlinux/zfs/commits/812e91a7e3abe59565462e4bb2a01724afddb042"},{"sha":"e3e670d0061ff121293dafb37d1f14a7069d49d5","author":{"email":"0962b5d2f5c1117073cf6f982c188f029b03d89e@delphix.com","name":"Matthew Ahrens"},"message":"Illumos 4953, 4954, 4955\n\n4953 zfs rename <snapshot> need not involve libshare\n4954 \"zfs create\" need not involve libshare if we are not sharing\n4955 libshare's get_zfs_dataset need not sort the datasets\nReviewed by: George Wilson <george.wilson@delphix.com>\nReviewed by: Sebastien Roy <sebastien.roy@delphix.com>\nReviewed by: Dan McDonald <danmcd@omniti.com>\nReviewed by: Gordon Ross <gordon.ross@nexenta.com>\nApproved by: Garrett D'Amore <garrett@damore.org>\n\nReferences:\n  https://www.illumos.org/issues/4953\n  https://www.illumos.org/issues/4954\n  https://www.illumos.org/issues/4955\n  https://github.com/illumos/illumos-gate/commit/33cde0d\n\nPorting notes:\n- Dropped qsort libshare_zfs.c hunk, no equivalent ZoL code.\n\nPorted-by: Brian Behlendorf <behlendorf1@llnl.gov>\nCloses #4219","distinct":true,"url":"https://api.github.com/repos/zfsonlinux/zfs/commits/e3e670d0061ff121293dafb37d1f14a7069d49d5"},{"sha":"bc89ac8479c0b265c539b579fda2bef1997d423c","author":{"email":"22b2eddf85561278a28f19eeca1c8e9e8ee2508e@nexenta.com","name":"Josef 'Jeff' Sipek"},"message":"Illumos 5045 - use atomic_{inc,dec}_* instead of atomic_add_*\n\n5045 use atomic_{inc,dec}_* instead of atomic_add_*\nReviewed by: Matthew Ahrens <mahrens@delphix.com>\nReviewed by: Garrett D'Amore <garrett@damore.org>\nApproved by: Robert Mustacchi <rm@joyent.com>\n\nReferences:\n  https://www.illumos.org/issues/5045\n  https://github.com/illumos/illumos-gate/commit/1a5e258\n\nPorting notes:\n- All changes to non-ZFS files dropped.\n- Changes to zfs_vfsops.c dropped because they were Illumos specific.\n\nPorted-by: Brian Behlendorf <behlendorf1@llnl.gov>\nCloses #4220","distinct":true,"url":"https://api.github.com/repos/zfsonlinux/zfs/commits/bc89ac8479c0b265c539b579fda2bef1997d423c"}]}