This project is mirrored from https://github.com/openzfs/zfs.git. Pull mirroring failed .
Last successful update .
  1. 22 Jan, 2022 5 commits
    • наб's avatar
      Fix test-runner on FreeBSD · 17b2ae0b
      наб authored
      
      
      CLOCK_MONOTONIC_RAW is only a thing on Linux and macOS. I'm not
      actually sure why the previous hardcoding of a constant didn't
      error out, but when we removed it, it sure does now.
      Reviewed-by: default avatarAlexander Motin <mav@FreeBSD.org>
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Co-authored-by: default avatarRich Ercolani <rincebrain@gmail.com>
      Signed-off-by: default avatarRich Ercolani <rincebrain@gmail.com>
      Closes #12995 
      17b2ae0b
    • Mark Johnston's avatar
      Fix handling of errors from dmu_write_uio_dbuf() on FreeBSD · 063daa83
      Mark Johnston authored
      
      
      FreeBSD's implementation of zfs_uio_fault_move() returns EFAULT when a
      page fault occurs while copying data in or out of user buffers.  The VFS
      treats such errors specially and will retry the I/O operation (which may
      have made some partial progress).
      
      When the FreeBSD and Linux implementations of zfs_write() were merged,
      the handling of errors from dmu_write_uio_dbuf() changed such that
      EFAULT is not handled as a partial write.  For example, when appending
      to a file, the z_size field of the znode is not updated after a partial
      write resulting in EFAULT.
      
      Restore the old handling of errors from dmu_write_uio_dbuf() to fix
      this.  This should have no impact on Linux, which has special handling
      for EFAULT already.
      Reviewed-by: default avatarAndriy Gapon <avg@FreeBSD.org>
      Reviewed-by: default avatarRyan Moeller <ryan@iXsystems.com>
      Signed-off-by: default avatarMark Johnston <markj@FreeBSD.org>
      Closes #12964 
      063daa83
    • George Amanakis's avatar
      Introduce a flag to skip comparing the local mac when raw sending · 63a26454
      George Amanakis authored
      
      
      Raw receiving a snapshot back to the originating dataset is currently
      impossible because of user accounting being present in the originating
      dataset.
      
      One solution would be resetting user accounting when raw receiving on
      the receiving dataset. However, to recalculate it we would have to dirty
      all dnodes, which may not be preferable on big datasets.
      
      Instead, we rely on the os_phys flag
      OBJSET_FLAG_USERACCOUNTING_COMPLETE to indicate that user accounting is
      incomplete when raw receiving. Thus, on the next mount of the receiving
      dataset the local mac protecting user accounting is zeroed out.
      The flag is then cleared when user accounting of the raw received
      snapshot is calculated.
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Signed-off-by: default avatarGeorge Amanakis <gamanakis@gmail.com>
      Closes #12981 
      Closes #10523
      Closes #11221
      Closes #11294
      Closes #12594
      Issue #11300
      63a26454
    • Mark Johnston's avatar
      Avoid memory allocations in the ARC eviction thread · 6e2a5918
      Mark Johnston authored
      
      
      When the eviction thread goes to shrink an ARC state, it allocates a set
      of marker buffers used to hold its place in the state's sublists.
      
      This can be problematic in low memory conditions, since
      1) the allocation can be substantial, as we allocate NCPU markers;
      2) on at least FreeBSD, page reclamation can block in
         arc_wait_for_eviction()
      
      In particular, in stress tests it's possible to hit a deadlock on
      FreeBSD when the number of free pages is very low, wherein the system is
      waiting for the page daemon to reclaim memory, the page daemon is
      waiting for the ARC eviction thread to finish, and the ARC eviction
      thread is blocked waiting for more memory.
      
      Try to reduce the likelihood of such deadlocks by pre-allocating markers
      for the eviction thread at ARC initialization time.  When evicting
      buffers from an ARC state, check to see if the current thread is the ARC
      eviction thread, and use the pre-allocated markers for that purpose
      rather than dynamically allocating them.
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Reviewed-by: default avatarAlexander Motin <mav@FreeBSD.org>
      Reviewed-by: default avatarGeorge Amanakis <gamanakis@gmail.com>
      Signed-off-by: default avatarMark Johnston <markj@FreeBSD.org>
      Closes #12985 
      6e2a5918
    • наб's avatar
      libspl: ASSERT*: !! for sizeof · bc40713a
      наб authored
      
      
      sizeof(bitfield.member) is invalid, and this shows up in some FreeBSD
      build configurations: work around this by !!ing ‒
      this makes the sizeof target the ! result type (_Bool), instead
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Signed-off-by: default avatarAhelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
      Fixes: 42aaf0e7 ("libspl: ASSERT*: mark arguments as used")
      Closes #12984
      Closes #12986
      bc40713a
  2. 21 Jan, 2022 1 commit
  3. 19 Jan, 2022 1 commit
  4. 15 Jan, 2022 5 commits
  5. 14 Jan, 2022 4 commits
  6. 13 Jan, 2022 2 commits
  7. 08 Jan, 2022 1 commit
  8. 07 Jan, 2022 19 commits
  9. 05 Jan, 2022 2 commits
    • chrisrd's avatar
      zfs_prune: reset sc.nr_to_scan · 2a149775
      chrisrd authored
      
      
      sc.nr_to_scan is an input to super_cache_clean (via
      shrinker->scan_objects), used to set the number of objects to scan
      in the various caches. However super_cache_scan also modifies
      sc.nr_to_scan, so when used in a loop we need to reset
      sc.nr_to_scan back to our desired nr_to_scan for the next
      iteration.
      
      Issue discovered and solution suggested by
      Tenzin Lhakhang @tlhakhan.
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Signed-off-by: default avatarChris Dunlop <chris@onthe.net.au>
      Issue #12433
      Closes #12908 
      2a149775
    • Brian Behlendorf's avatar
      Verify dRAID empty sectors · 3c80e074
      Brian Behlendorf authored
      
      
      Verify that all empty sectors are zero filled before using them to
      calculate parity.  Failure to do so can result in incorrect parity
      columns being generated and written to disk if the contents of an
      empty sector are non-zero.  This was possible because the checksum
      only protects the data portions of the buffer, not the empty sector
      padding.
      
      This issue has been addressed by updating raidz_parity_verify() to
      check that all dRAID empty sectors are zero filled.  Any sectors
      which are non-zero will be fixed, repair IO issued, and a checksum
      error logged.  They can then be safely used to verify the parity.
      
      This specific type of damage is unlikely to occur since it requires
      a disk to have silently returned bad data, for an empty sector, while
      performing a scrub.  However, if a pool were to have been damaged
      in this way, scrubbing the pool with this change applied will repair
      both the empty sector and parity columns as long as the data checksum
      is valid.  Checksum errors will be reported in the `zpool status`
      output for any repairs which are made.
      Reviewed-by: default avatarTony Hutter <hutter2@llnl.gov>
      Reviewed-by: default avatarMark Maybee <mark.maybee@delphix.com>
      Reviewed-by: default avatarBrian Atkinson <batkinson@lanl.gov>
      Signed-off-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Closes #12857 
      3c80e074