1. 24 Feb, 2021 7 commits
  2. 21 Feb, 2021 4 commits
  3. 20 Feb, 2021 6 commits
  4. 18 Feb, 2021 4 commits
    • Mark Johnston's avatar
      FreeBSD: disable the use of hardware crypto offload drivers for now · e7adccf7
      Mark Johnston authored
      
      First, the crypto request completion handler contains a bug in that it
      fails to reset fs_done correctly after the request is completed.  This
      is only a problem for asynchronous drivers.  Second, some hardware
      drivers have input constraints which ZFS does not satisfy.  For
      instance, ccp(4) apparently requires the AAD length for AES-GCM to be a
      multiple of the cipher block size, and with qat(4) the AES-GCM AAD
      length may not be longer than 240 bytes.  FreeBSD's generic crypto
      framework doesn't have a mechanism to automatically fall back to a
      software implementation if a hardware driver cannot process a request,
      and ZFS does not tolerate such errors.
      
      The plan is to implement such a fallback mechanism, but with FreeBSD
      13.0 approaching we should simply disable the use hardware drivers for
      now.
      Reviewed-by: default avatarRyan Moeller <ryan@iXsystems.com>
      Reviewed-by: default avatarAlexander Motin <mav@FreeBSD.org>
      Signed-off-by: default avatarMark Johnston <markj@FreeBSD.org>
      Closes #11612 
      e7adccf7
    • Andriy Gapon's avatar
      Fix report_mount_progress never calling set_progress_header · 778869fa
      Andriy Gapon authored
      That happens because of an off-by-one mistake.
      share_mount_one_cb() calls report_mount_progress(current=sm_done) after
      having incremented sm_done by one.  Then report_mount_progress()
      increments the parameter again.  It appears that that logic became
      obsolete after commit a10d50f9
      
      , parallel zfs mount.
      
      On FreeBSD I observe that zfs mount -a -v prints, for example,
          (null): (201/248)
      That happens because set_progress_header() is never called.
      
      With this change the output becomes correct:
          Mounting ZFS filesystems: (209/248)
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Signed-off-by: default avatarAndriy Gapon <avg@FreeBSD.org>
      Closes #11607 
      778869fa
    • Ryan Libby's avatar
      Remove unused abd_alloc_scatter_offset_chunkcnt · bf156c96
      Ryan Libby authored
      Remove function that become unused after refactoring in
      e2af2acc
      
      .
      Reviewed-by: default avatarRyan Moeller <ryan@ixsystems.com>
      Reviewed-by: default avatarMatthew Ahrens <mahrens@delphix.com>
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Signed-off-by: default avatarRyan Libby <rlibby@FreeBSD.org>
      Closes #11614 
      bf156c96
    • Colm's avatar
      Add "compatibility" property for zpool feature sets · 658fb802
      Colm authored
      
      Property to allow sets of features to be specified; for compatibility
      with specific versions / releases / external systems. Influences
      the behavior of 'zpool upgrade' and 'zpool create'. Initial man
      page changes and test cases included.
      
      Brief synopsis:
      
      zpool create -o compatibility=off|legacy|file[,file...] pool vdev...
      
      compatibility = off : disable compatibility mode (enable all features)
      compatibility = legacy : request that no features be enabled
      compatibility = file[,file...] : read features from specified files.
      Only features present in *all* files will be enabled on the
      resulting pool. Filenames may be absolute, or relative to
      /etc/zfs/compatibility.d or /usr/share/zfs/compatibility.d (/etc
      checked first).
      
      Only affects zpool create, zpool upgrade and zpool status.
      
      ABI changes in libzfs:
      
      * New function "zpool_load_compat" to load and parse compat sets.
      * Add "zpool_compat_status_t" typedef for compatibility parse status.
      * Add ZPOOL_PROP_COMPATIBILITY to the pool properties enum
      * Add ZPOOL_STATUS_COMPATIBILITY_ERR to the pool status enum
      
      An initial set of base compatibility sets are included in
      cmd/zpool/compatibility.d, and the Makefile for cmd/zpool is
      modified to install these in $pkgdatadir/compatibility.d and to
      create symbolic links to a reasonable set of aliases.
      
      Reviewed-by: ericloewe
      Reviewed-by: default avatarMatthew Ahrens <mahrens@delphix.com>
      Reviewed-by: default avatarRichard Laager <rlaager@wiktel.com>
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Signed-off-by: default avatarColm Buckley <colm@tuatha.org>
      Closes #11468 
      658fb802
  5. 17 Feb, 2021 2 commits
  6. 15 Feb, 2021 1 commit
  7. 10 Feb, 2021 1 commit
  8. 09 Feb, 2021 3 commits
    • Arshad Hussain's avatar
      vdev_id: Support daisy-chained JBODs in multipath mode · 677cdf78
      Arshad Hussain authored
      
      Within function sas_handler() userspace commands like
      '/usr/sbin/multipath' have been replaced with sourcing
      device details from within sysfs which reduced a
      significant amount of overhead and processing time.
      Multiple JBOD enclosures and their order are sourced
      from the bsg driver (/sys/class/enclosure) to isolate
      chassis top-level expanders, which are then dynamically
      indexed based on host channel of the multipath subordinate
      disk member device being processed. Additionally added a
      "mixed" mode for slot identification for environments where
      a ZFS server system may contain SAS disk slots where there
      is no expander (direct connect to HBA) while an attached
      external JBOD with an expander have different slot identifier
      methods.
      
      How Has This Been Tested?
      ~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Testing was performed on a AMD EPYC based dual-server
      high-availability multipath environment with multiple
      HBAs per ZFS server and four SAS JBODs. The two primary
      JBODs were multipath/cross-connected between the two
      ZFS-HA servers. The secondary JBODs were daisy-chained
      off of the primary JBODs using aligned SAS expander
      channels (JBOD-0 expanderA--->JBOD-1 expanderA,
                JBOD-0 expanderB--->JBOD-1 expanderB, etc).
      Pools were created, exported and re-imported, imported
      globally with 'zpool import -a -d /dev/disk/by-vdev'.
      Low level udev debug outputs were traced to isolate
      and resolve errors.
      
      Result:
      ~~~~~~~
      
      Initial testing of a previous version of this change
      showed how reliance on userspace utilities like
      '/usr/sbin/multipath' and '/usr/bin/lsscsi' were
      exacerbated by increasing numbers of disks and JBODs.
      With four 60-disk SAS JBODs and 240 disks the time to
      process a udevadm trigger was 3 minutes 30 seconds
      during which nearly all CPU cores were above 80%
      utilization. By switching reliance on userspace
      utilities to sysfs in this version, the udevadm
      trigger processing time was reduced to 12.2 seconds
      and negligible CPU load.
      
      This patch also fixes few shellcheck complains.
      Reviewed-by: default avatarGabriel A. Devenyi <gdevenyi@gmail.com>
      Reviewed-by: default avatarTony Hutter <hutter2@llnl.gov>
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Co-authored-by: default avatarJeff Johnson <jeff.johnson@aeoncomputing.com>
      Signed-off-by: default avatarJeff Johnson <jeff.johnson@aeoncomputing.com>
      Signed-off-by: default avatarArshad Hussain <arshad.hussain@aeoncomputing.com>
      Closes #11526 
      677cdf78
    • khng300's avatar
      Rename zfs_inode_update to zfs_znode_update_vfs · fc273894
      khng300 authored
      
      zfs_znode_update_vfs is a more platform-agnostic name than
      zfs_inode_update. Besides that, the function's prototype is moved to
      include/sys/zfs_znode.h as the function is also used in common code.
      Reviewed-by: default avatarRyan Moeller <ryan@ixsystems.com>
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Signed-off-by: default avatarKa Ho Ng <khng300@gmail.com>
      Sponsored by: The FreeBSD Foundation
      Closes #11580 
      fc273894
    • Kleber Tarcísio's avatar
      Add an assert to clarify code · 4f22619a
      Kleber Tarcísio authored
      
      The first time through the loop prevdb and prevhdl are NULL.  They 
      are then both set, but only prevdb is checked.  Add an ASSERT to 
      make it clear that prevhdl must be set when prevdb is.
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Signed-off-by: default avatarKleber <klebertarcisio@yahoo.com.br>
      Closes #10754
      Closes #11575 
      4f22619a
  9. 08 Feb, 2021 1 commit
    • Antonio Russo's avatar
      Set file mode during zfs_write · f8ce8aed
      Antonio Russo authored
      3d40b655 refactored zfs_vnops.c, which shared much code verbatim between
      Linux and BSD.  After a successful write, the suid/sgid bits are reset,
      and the mode to be written is stored in newmode.  On Linux, this was
      propagated to both the in-memory inode and znode, which is then updated
      with sa_update.
      
      3d40b655
      
       accidentally removed the initialization of newmode, which
      happened to occur on the same line as the inode update (which has been
      moved out of the function).
      
      The uninitialized newmode can be saved to disk, leading to a crash on
      stat() of that file, in addition to a merely incorrect file mode.
      Reviewed-by: default avatarRyan Moeller <ryan@ixsystems.com>
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Signed-off-by: default avatarAntonio Russo <aerusso@aerusso.net>
      Closes #11474 
      Closes #11576 
      f8ce8aed
  10. 05 Feb, 2021 2 commits
  11. 04 Feb, 2021 1 commit
  12. 02 Feb, 2021 4 commits
  13. 30 Jan, 2021 2 commits
  14. 29 Jan, 2021 2 commits