1. 31 Mar, 2022 1 commit
  2. 29 Mar, 2022 1 commit
  3. 28 Mar, 2022 1 commit
  4. 27 Mar, 2022 1 commit
    • Andrew's avatar
      NAS-115465 / 22.12 / expose ZFS_ACL_TRIVIAL to users (#52) · 4a280f30
      Andrew authored
      
      Add ACL_IS_TRIVIAL and ACL_IS_DIR flags as ACL-wide flags
      in the system.nfs4_acl_xdr generated on getxattr requests.
      
      This are non-RFC flags that are useful for userspace applications
      (especially the ACL_IS_TRIVIAL flag as it can be used to avoid
      relatively expensive ACL-related operations).
      
      Also add system.nfs4_acl_xdr to xattr results if ACL is not trivial.
      This duplicates POSIX ACL behavior where whether an ACL is
      set on a path can be determined via listxattr(). Since the ACL
      is not actually removed, we check whether the ZFS_ACL_TRIVIAL
      is set. If the flag is not set, then we omit the xattr name from
      the list. This allows users to determine whether ACL is trivial from
      listxattr().
      Signed-off-by: default avatarAndrew Walker <awalker@ixsystems.com>
      4a280f30
  5. 21 Mar, 2022 2 commits
  6. 18 Mar, 2022 2 commits
    • Tony Hutter's avatar
      zed: Fix mpath autoreplace on Centos 7 · 2b8b89c6
      Tony Hutter authored
      A prior commit included a udev check for MPATH_DEVICE_READY to
      determine if a path was multipath when doing an autoreplace:
      
          f2f6c18f
      
       zed: Misc multipath autoreplace fixes
      
      However, MPATH_DEVICE_READY is not provided by the older version of
      udev that's on Centos 7 (it is on Centos 8).
      
      This patch instead looks for 'mpath-' in the UUID, which works on
      both Centos 7 and 8.
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Signed-off-by: default avatarTony Hutter <hutter2@llnl.gov>
      Closes #13222 
      2b8b89c6
    • Tony Hutter's avatar
      zed: Misc multipath autoreplace fixes · 90abfdf8
      Tony Hutter authored
      
      We recently had a case where our operators replaced a bad
      multipathed disk, only to see it fail to autoreplace.  The
      zed logs showed that the multipath replacement disk did not pass
      the 'is_dm' test in zfs_process_add() even though it should have.
      is_dm is set if there exists a sysfs entry for to the
      underlying /dev/sd* paths for the multipath disk.  It's
      possible this path didn't exist due to a race condition where
      the sysfs paths weren't created at the time the udev event came
      in to zed, but this was never verified.
      
      This patch updates the check to look for udev properties that
      indicate if the new autoreplace disk is an empty multipath disk,
      rather than looking for the underlying sysfs entries. It also
      adds in additional logging, and fixes a bug where zed allowed
      you to use an already zfs-formatted disk from another pool
      as a multipath auto-replacement disk.
      
      Furthermore, while testing this patch, I also ran across a case
      where a force-faulted disk did not have a ZPOOL_CONFIG_PHYS_PATH
      entry in its config.  This prevented it from being autoreplaced.
      I added additional logic to derive the PHYS_PATH from the PATH if
      the PATH was a /dev/disk/by-vdev/ path.  For example, if PATH
      was /dev/disk/by-vdev/L28, then PHYS_PATH would be L28.  This is
      safe since by-vdev paths represent physical locations and do not
      change between boots.
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Signed-off-by: default avatarTony Hutter <hutter2@llnl.gov>
      Closes #13023 
      90abfdf8
  7. 21 Mar, 2022 1 commit
  8. 19 Mar, 2022 3 commits
  9. 17 Mar, 2022 2 commits
  10. 11 Mar, 2022 1 commit
  11. 10 Mar, 2022 2 commits
  12. 09 Mar, 2022 3 commits
  13. 08 Mar, 2022 1 commit
    • Brian Behlendorf's avatar
      Fix ENOSPC when unlinking multiple files from full pool · 145af480
      Brian Behlendorf authored
      
      When unlinking multiple files from a pool at 100% capacity, it was
      possible for ENOSPC to be returned after the first unlink.  e.g.
      
          rm -f /mnt/fs/test1.0.0 /mnt/fs/test1.1.0 /mnt/fs/test1.2.0
          rm: cannot remove '/mnt/fs/test1.1.0': No space left on device
          rm: cannot remove '/mnt/fs/test1.2.0': No space left on device
      
      After waiting for the pending deferred frees from the first unlink to
      be processed the remaining files can then be unlinked.  This is caused
      by the quota limit in dsl_dir_tempreserve_impl() being temporarily
      decreased to the allocatable pool capacity less any deferred free
      space.
      
      This is resolved using the existing mechanism of returning ERESTART
      when over quota as long as we know enough space will shortly be
      available after processing the pending deferred frees.
      Reviewed-by: default avatarAlexander Motin <mav@FreeBSD.org>
      Reviewed-by: default avatarRyan Moeller <freqlabs@FreeBSD.org>
      Reviewed-by: default avatarTony Hutter <hutter2@llnl.gov>
      Signed-off-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Closes #13172
      145af480
  14. 07 Mar, 2022 1 commit
  15. 04 Mar, 2022 2 commits
    • Mark Johnston's avatar
      zfs: Fix a deadlock between page busy and the teardown lock · b3427b18
      Mark Johnston authored
      When rolling back a dataset, ZFS has to purge file data resident in the
      system page cache.  To do this, it loops over all vnodes for the
      mountpoint and calls vn_pages_remove() to purge pages associated with
      the vnode's VM object.  Each page is thus exclusively busied while the
      dataset's teardown write lock is held.
      
      When handling a page fault on a mapped ZFS file, FreeBSD's page fault
      handler busies newly allocated pages and then uses VOP_GETPAGES to fill
      them.  The ZFS getpages VOP acquires the teardown read lock with vnode
      pages already busied.  This represents a lock order reversal which can
      lead to deadlock.
      
      To break the deadlock, observe that zfs_rezget() need only purge those
      pages marked valid, and that pages busied by the page fault handler are,
      by definition, invalid.  Furthermore, ZFS pages always transition from
      invalid to valid with the teardown lock held, and ZFS never creates
      partially valid pages.  Thus, zfs_rezget() can use the new
      vn_pages_remove_valid() to skip over pages busied by the fault handler.
      
      PR:		258208
      Tested by:	pho
      Reviewed by:	avg, sef, kib
      MFC after:	2 weeks
      Sponsored by:	The FreeBSD Foundation
      Differential Revision:	https://reviews.freebsd.org/D32931
      
      Reviewed-by: default avatarTony Hutter <hutter2@llnl.gov>
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Reviewed-by: default avatarAlexander Motin <mav@FreeBSD.org>
      Signed-off-by: default avatarRyan Moeller <freqlabs@FreeBSD.org>
      Closes #12828
      b3427b18
    • Alexander Motin's avatar
      Really zero the zero page · 0e2bb1a3
      Alexander Motin authored
      
      While switching abd_zero_buf allocation KPI I've missed the fact
      that kmem_zalloc() zeroed the allocation, while kmem_cache_alloc()
      does not.  Add explicit bzero() after it.
      
      I don't think it should have caused real problems, but leaking one
      memory page content all over the pool is not good.
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Reviewed-by: default avatarBrian Atkinson <batkinson@lanl.gov>
      Reviewed-by: default avatarRyan Moeller <ryan@ixsystems.com>
      Signed-off-by: default avatarAlexander Motin <mav@FreeBSD.org>
      Closes #12569
      0e2bb1a3
  16. 02 Mar, 2022 2 commits
    • Brian Behlendorf's avatar
      ZTS: Fix import_devices_missing.ksh · 037434e4
      Brian Behlendorf authored
      Related to commit 90b77a03
      
      .  Retry the `zpool export` if the pool
      is "busy" indicating there is a process accessing the mount point.
      This can happen after an import, allowing it to be retried will
      avoid spurious test failures.
      Reviewed-by: default avatarTony Hutter <hutter2@llnl.gov>
      Signed-off-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Closes #13169
      037434e4
    • Brian Behlendorf's avatar
      ZTS: Retry in import_rewind_config_changed.ksh · 190516f0
      Brian Behlendorf authored
      
      As explained by the disclaimer in the test case,
      
          "This test can fail since nothing guarantees that old
          MOS blocks aren't overwritten."
      
      This behavior is expected and correct, but results in a
      flaky test case which is problematic for the CI.  The best
      we can do to resolve this is to retry the sub-test which
      failed when the MOS blocks have clearly been overwritten.
      
      When testing failures were rare enough that a single retry
      should normally be sufficient.  However, we allow up to
      five for good measure.
      
      Reviewed by: George Melikov <mail@gmelikov.ru>
      Signed-off-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Closes #13119
      190516f0
  17. 01 Mar, 2022 3 commits
  18. 25 Feb, 2022 2 commits
  19. 22 Feb, 2022 9 commits