GitHub PushEvent at 2014-07-03 05:33:24
Repository: zfs
Actor: rohan-puri
Payload: {"shas":[["ada8ec1ec5b0bfdab74bafda49e2f7a67dc7101d","daf6a3eb8e07ffc2ae288040ae2f4d32859889a6@gmail.com","Allow leading digits in userquota/groupquota names\n\nWhile setting/getting userquota and groupquota properties, the input\nwas not treated as a possible username or groupname if it had a\nleading digit. While useradd in linux recommends the regexp\n[a-z_][a-z0-9_-]*[$]? , it is not enforced. This causes problem for\nusernames with leading digits in them. We need to be able to support\ngetting and setting properties for this unconventional but possible\ninput category\n\nI've updated the code to validate the username or groupname directly\nvia the API. Also, note that I moved this validation to the beginning\nbefore the check for SID names with @. This also supports usernames\nwith @ character in them which are valid. Only when input with @ is\nnot a valid username, it is interpreted as a potential SID name.\n\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nCloses #428","Suman Chakravartula",true],["e89236fd28cbe8585146b8b5d0ced1f8d4aa8431","24a77266642cd4a4ef2cfe7b1b51cf15e514d3c3@llnl.gov","In autoconf v2.68, AC_LANG_PROGRAM must be quoted\n\nThis change updates the AC_LANG_PROGRAM autoconf macro invocations to be\nwrapped in quotes. As of autoconf version 2.68, the quotes are necessary\nto prevent warnings from appearing. Specifically, the autoconf v2.68\nForward Porting Notes specifies:\n\n    It is important to note that you need to ensure that the call to\n    AC_LANG_SOURCE is quoted and not expanded, otherwise that will\n    cause the warning to appear nonetheless.\n\nFinally, because of the additional quoting we can drop the extra\nquotas used by the ZFS_AC_CONFIG_USER_STACK_GUARD autoconf check.\n\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nCloses #464","Prakash Surya",true],["82a37189aac955c81a59a5ecc3400475adb56355","32d50ad1e384dcb9a5bf7e40fa470df5dabaf348@llnl.gov","Implement SA based xattrs\n\nThe current ZFS implementation stores xattrs on disk using a hidden\ndirectory.  In this directory a file name represents the xattr name\nand the file contexts are the xattr binary data.  This approach is\nvery flexible and allows for arbitrarily large xattrs.  However,\nit also suffers from a significant performance penalty.  Accessing\na single xattr can requires up to three disk seeks.\n\n  1) Lookup the dnode object.\n  2) Lookup the dnodes's xattr directory object.\n  3) Lookup the xattr object in the directory.\n\nTo avoid this performance penalty Linux filesystems such as ext3\nand xfs try to store the xattr as part of the inode on disk.  When\nthe xattr is to large to store in the inode then a single external\nblock is allocated for them.  In practice most xattrs are small\nand this approach works well.\n\nThe addition of System Attributes (SA) to zfs provides us a clean\nway to make this optimization.  When the dataset property 'xattr=sa'\nis set then xattrs will be preferentially stored as System Attributes.\nThis allows tiny xattrs (~100 bytes) to be stored with the dnode and\nup to 64k of xattrs to be stored in the spill block.  If additional\nxattr space is required, which is unlikely under Linux, they will be\nstored using the traditional directory approach.\n\nThis optimization results in roughly a 3x performance improvement\nwhen accessing xattrs which brings zfs roughly to parity with ext4\nand xfs (see table below).  When multiple xattrs are stored per-file\nthe performance improvements are even greater because all of the\nxattrs stored in the spill block will be cached.\n\nHowever, by default SA based xattrs are disabled in the Linux port\nto maximize compatibility with other implementations.  If you do\nenable SA based xattrs then they will not be visible on platforms\nwhich do not support this feature.\n\n----------------------------------------------------------------------\n   Time in seconds to get/set one xattr of N bytes on 100,000 files\n------+--------------------------------+------------------------------\n      |            setxattr            |            getxattr\nbytes |  ext4     xfs zfs-dir  zfs-sa  |  ext4     xfs zfs-dir  zfs-sa\n------+--------------------------------+------------------------------\n1     |  2.33   31.88   21.50    4.57  |  2.35    2.64    6.29    2.43\n32    |  2.79   30.68   21.98    4.60  |  2.44    2.59    6.78    2.48\n256   |  3.25   31.99   21.36    5.92  |  2.32    2.71    6.22    3.14\n1024  |  3.30   32.61   22.83    8.45  |  2.40    2.79    6.24    3.27\n4096  |  3.57  317.46   22.52   10.73  |  2.78   28.62    6.90    3.94\n16384 |   n/a 2342.39   34.30   19.20  |   n/a   45.44  145.90    7.55\n65536 |   n/a 2941.39  128.15  131.32* |   n/a  141.92  256.85  262.12*\n\nLegend:\n* ext4      - Stock RHEL6.1 ext4 mounted with '-o user_xattr'.\n* xfs       - Stock RHEL6.1 xfs mounted with default options.\n* zfs-dir   - Directory based xattrs only.\n* zfs-sa    - Prefer SAs but spill in to directories as needed, a\n              trailing * indicates overflow in to directories occured.\n\nNOTE: Ext4 supports 4096 bytes of xattr name/value pairs per file.\nNOTE: XFS and ZFS have no limit on xattr name/value pairs per file.\nNOTE: Linux limits individual name/value pairs to 65536 bytes.\nNOTE: All setattr/getattr's were done after dropping the cache.\nNOTE: All tests were run against a single hard drive.\n\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nIssue #443","Brian Behlendorf",true],["f31b3ebe6e6c9de4db30bf752c09a8300b305258","32d50ad1e384dcb9a5bf7e40fa470df5dabaf348@llnl.gov","Allow xattrs on symlinks\n\nThe Solaris version of ZFS does not allow xattrs to be set on\nsymlinks due to the way they implemented the attropen() system\ncall.  Linux however implements xattrs through the lgetxattr()\nand lsetxattr() system calls which do not have this limitation.\n\nThe only reason this hasn't always worked under ZFS on Linux\nis that the xattr handlers were not registered for symlink type\ninodes.  This was done simply to be consistent with the Solaris\nbehavior.\n\nUpon futher reflection I believe this should be allowed under\nLinux.  The only ill effect would be that the xattrs on symlinks\nwill not be visible when the pool is imported on a Solaris\nsystem.  This also has the benefit that it allows for SELinux\nstyle security xattr labeling which expects to be able to set\nxattrs on all inode types.\n\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nCloses #272","Brian Behlendorf",true],["b9c59ec83ab50e1cd097f067461e34a5750694c8","24a77266642cd4a4ef2cfe7b1b51cf15e514d3c3@llnl.gov","Fix configure tests to play nice with GCC 4.6\n\nAs of GCC 4.6, specific kernel 2.6.32 header files do not compile\ncleanly without warnings. One specific example of this is the\narch/x86/include/asm/percpu.h file. Thus, a few of the configure tests\nwere getting hung up on this and the '-Wno-unsued-but-set-variables'\ncompile option had to be introduced.\n\nSigned-off-by: Prakash Surya <surya1@llnl.gov>\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nCloses #459","Prakash Surya",true],["590338f63ee0db6f1fc7e6b5b23744d3944777b2","79778dbbdd172ad4142b370229409ecedf95bcb5@beutner.name","Added comments for libshare's NFS functions.\n\nSome of the functions' purpose wasn't immediately obvious without\nadditional explanations. This commit adds these missing comments.\n\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>","Gunnar Beutner",true],["9c8254f6f95b2b08e2031b2682a632e0df45cefb","5d062318501a5e60dc639e1749c062a2fed12014@vanadac.com","Support path_id changes in udev 174.\n\nThe /lib/udev/path_id helper became a builtin command in the udev 174\nrelease, so test whether path_id is external in the zpool_id script.\n\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nCloses: #429","Darik Horn",true],["04bf5ecc1f04ed5955ab9951c833d6b08db57356","5d062318501a5e60dc639e1749c062a2fed12014@vanadac.com","Quote variables in the zpool_id script.\n\nFor consistency and safety, quote all variables in the zpool_id\nscript. This accomodates a `-c CONFIG` parameter value with\nwhitespace in the path name.\n\nAlso fix a typo in the usage synopsis for `-h`.\n\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nIssue #439","Darik Horn",true],["87193e2b6111d6080df90c2c8e03ce49b14e031a","5d062318501a5e60dc639e1749c062a2fed12014@vanadac.com","Demote egrep to grep in the zpool_id script.\n\nDirect invocation of GNU egrep is deprecated by its man page, and the\nits argument in the zpool_id script is not an extended expression.\n\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>","Darik Horn",true],["db7c1771da2634af4e2a4323759656c7f0afe689","5d062318501a5e60dc639e1749c062a2fed12014@vanadac.com","Demote the whackbang in the zpool_id script.\n\nThe zpool_id script is posixly correct and does not use bash\nfeatures, so change its whackbang from /bin/bash to /bin/sh.\n\nDebian policy also stipulates that system scripts be dash compatible.\n\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>","Darik Horn",true],["c2d9c41d5084db354d80c03fea4fb0bb97327c0a","5d062318501a5e60dc639e1749c062a2fed12014@vanadac.com","Source /etc/default/zfs after setting defaults.\n\nLet the administrator override all script variables by sourcing the\n/etc/default/zfs file after the default values are set.\n\nThe spelling mistake in the old path name makes it unlikely that this\nbug affected any users.\n\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nCloses: #371","Darik Horn",true],["660cbada0fca3b5504562adcf21a35f9195f46a0","5d062318501a5e60dc639e1749c062a2fed12014@vanadac.com","Quote variables in the zfs.lsb script.\n\nFor consistency and safety, quote all variables in the zfs.lsb script.\nThis protects in the unlikely case that any of the file names contain\nwhitespace.\n\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nIssue #439","Darik Horn",true],["23bdb07d4e4c435205d25d3efdb5fef2d089ce5e","32d50ad1e384dcb9a5bf7e40fa470df5dabaf348@llnl.gov","Update default ARC memory limits\n\nIn the upstream OpenSolaris ZFS code the maximum ARC usage is\nlimited to 3/4 of memory or all but 1GB, whichever is larger.\nBecause of how Linux's VM subsystem is organized these defaults\nhave proven to be too large which can lead to stability issues.\n\nTo avoid making everyone manually tune the ARC the defaults are\nbeing changed to 1/2 of memory or all but 4GB.  The rational for\nthis is as follows:\n\n* Desktop Systems (less than 8GB of memory)\n\n  Limiting the ARC to 1/2 of memory is desirable for desktop\n  systems which have highly dynamic memory requirements.  For\n  example, launching your web browser can suddenly result in a\n  demand for several gigabytes of memory.  This memory must be\n  reclaimed from the ARC cache which can take some time.  The\n  user will experience this reclaim time as a sluggish system\n  with poor interactive performance.  Thus in this case it is\n  preferable to leave the memory as free and available for\n  immediate use.\n\n* Server Systems (more than 8GB of memory)\n\n  Using all but 4GB of memory for the ARC is preferable for\n  server systems.  These systems often run with minimal user\n  interaction and have long running daemons with relatively\n  stable memory demands.  These systems will benefit most by\n  having as much data cached in memory as possible.\n\nThese values should work well for most configurations.  However,\nif you have a desktop system with more than 8GB of memory you may\nwish to further restrict the ARC.  This can still be accomplished\nby setting the 'zfs_arc_max' module option.\n\nAdditionally, keep in mind these aren't currently hard limits.\nThe ARC is based on a slab implementation which can suffer from\nmemory fragmentation.  Because this fragmentation is not visible\nfrom the ARC it may believe it is within the specified limits while\nactually consuming slightly more memory.  How much more memory get's\nconsumed will be determined by how badly fragmented the slabs are.\n\nIn the long term this can be mitigated by slab defragmentation code\nwhich was OpenSolaris solution.  Or preferably, using the page cache\nto back the ARC under Linux would be even better.  See issue #75\nfor the benefits of more tightly integrating with the page cache.\n\nThis change also fixes a issue where the default ARC max was being\nset incorrectly for machines with less than 2GB of memory.  The\nconstant in the arc_c_max comparison must be explicitly cast to\na uint64_t type to prevent overflow and the wrong conditional\nbranch being taken.  This failure was typically observed in VMs\nwhich are commonly created with less than 2GB of memory.\n\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nIssue #75","Brian Behlendorf",true],["30a9524e45f76d4c7860bcbf5567aeaa8aeb7a82","32d50ad1e384dcb9a5bf7e40fa470df5dabaf348@llnl.gov","Set zvol_major/zvol_threads permissions\n\nThe zvol_major and zvol_threads module options were being created\nwith 0 permission bits.  This prevented them from being listed in\nthe /sys/module/zfs/parameters/ directory, although they were\nvisible in `modinfo zfs`.  This patch fixes the issue by updating\nthe permission bits to 0444.  For the moment these options must\nbe read-only because they are used during module initialization.\n\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nIssue #392","Brian Behlendorf",true],["a38718a63d79116d6cb614dd2821e2a3955e5c8c","3d16c00ea5e6ea0de3ce0a04724885f2fc30401a@nexenta.com","Illumos #734: Use taskq_dispatch_ent() interface\n\nIt has been observed that some of the hottest locks are those\nof the zio taskqs.  Contention on these locks can limit the\nrate at which zios are dispatched which limits performance.\n\nThis upstream change from Illumos uses new interface to the\ntaskqs which allow them to utilize a prealloc'ed taskq_ent_t.\nThis removes the need to perform an allocation at dispatch\ntime while holding the contended lock.  This has the effect\nof improving system performance.\n\nReviewed by: Albert Lee <trisk@nexenta.com>\nReviewed by: Richard Lowe <richlowe@richlowe.net>\nReviewed by: Alexey Zaytsev <alexey.zaytsev@nexenta.com>\nReviewed by: Jason Brian King <jason.brian.king@gmail.com>\nReviewed by: George Wilson <gwilson@zfsmail.com>\nReviewed by: Adam Leventhal <ahl@delphix.com>\nApproved by: Gordon Ross <gwr@nexenta.com>\n\nReferences to Illumos issue:\n  https://www.illumos.org/issues/734\n\nPorted-by: Prakash Surya <surya1@llnl.gov>\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nCloses #482","Garrett D'Amore",true],["6ba3b44614fa6482bd2d7363964b65f0289b0f4f","24a77266642cd4a4ef2cfe7b1b51cf15e514d3c3@llnl.gov","Add make rule for building Arch Linux packages\n\nAdded the necessary build infrastructure for building packages\ncompatible with the Arch Linux distribution. As such, one can now run:\n\n    $ ./configure\n    $ make pkg     # Alternatively, one can run 'make arch' as well\n\non the Arch Linux machine to create two binary packages compatible with\nthe pacman package manager, one for the zfs userland utilities and\nanother for the zfs kernel modules. The new packages can then be\ninstalled by running:\n\n    # pacman -U $package.pkg.tar.xz\n\nIn addition, source-only packages suitable for an Arch Linux chroot\nenvironment or remote builder can also be build using the 'sarch' make\nrule.\n\nNOTE: Since the source dist tarball is created on the fly from the head\nof the build tree, it's MD5 hash signature will be continually influx.\nAs a result, the md5sum variable was intentionally omitted from the\nPKGBUILD files, and the '--skipinteg' makepkg option is used. This may\nor may not have any serious security implications, as the source tarball\nis not being downloaded from an outside source.\n\nSigned-off-by: Prakash Surya <surya1@llnl.gov>\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nCloses #491","Prakash Surya",true],["e6101ea87f5127c549d520aad124290857218fa5","5d062318501a5e60dc639e1749c062a2fed12014@vanadac.com","Update the character class in the zpool man page.\n\nZoL and all Solaris derivatives allow pool names to contain the colon\nand space characters. Update the man page to reflect current behavior.\n\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nCloses: #438","Darik Horn",true],["28eb9213d89cb25438fcecb86e735cc3edc26ea4","5d062318501a5e60dc639e1749c062a2fed12014@vanadac.com","Linux 3.2 compat: set_nlink()\n\nDirectly changing inode->i_nlink is deprecated in Linux 3.2 by commit\n\n  SHA: bfe8684869601dacfcb2cd69ef8cfd9045f62170\n\nUse the new set_nlink() kernel function instead.\n\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nCloses: #462","Darik Horn",true],["afd7da0ce72c3b3554079644d73e90fe6d2bf955","5d062318501a5e60dc639e1749c062a2fed12014@vanadac.com","Add LIBSELINUX to mount_zfs_LDFLAGS.\n\nRegenerating the autotools configuration on Debian and Ubuntu systems\ncauses compilation to fail with this error message:\n\n  cmd/mount_zfs/../../cmd/mount_zfs/mount_zfs.c:403:\n    undefined reference to `is_selinux_enabled'\n\nIn the automake template, set \"mount_zfs_LDFLAGS = ... $(LIBSELINUX)\"\nso that the /sbin/mount.zfs utility is linked to libselinux.\n\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>","Darik Horn",true],["8eaa020b46e80b09cc5f924b90809e219ce08e75","24a77266642cd4a4ef2cfe7b1b51cf15e514d3c3@llnl.gov","Move Arch Linux's VENDOR check above Ubuntu's\n\nIf the lsb-release package is installed on an Arch Linux distribution,\nthe configure step will incorrectly detect the running distribution as\nUbuntu. This is a result of both distributions providing an\n/etc/lsb-release file, and the Ubuntu VENDOR check being performed\nfirst.\n\nSince the Arch Linux test check's for a file more specific to the Arch\nLinux distribution, moving Arch Linux's VENDOR check above Unbuntu's\ncheck provides a quick and easy solution.\n\nSigned-off-by: Prakash Surya <surya1@llnl.gov>\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>","Prakash Surya",true]],"size":864,"ref":"refs/heads/master","head":"61e99a73bc34d602639c5a991abdc1e011a52d8d"}