1. 12 Mar, 2021 7 commits
  2. 08 Mar, 2021 3 commits
  3. 07 Mar, 2021 4 commits
    • Christian Schwarz's avatar
      zvol: call zil_replaying() during replay · 93e36580
      Christian Schwarz authored
      
      zil_replaying(zil, tx) has the side-effect of informing the ZIL that an
      entry has been replayed in the (still open) tx.  The ZIL uses that
      information to record the replay progress in the ZIL header when that
      tx's txg syncs.
      
      ZPL log entries are not idempotent and logically dependent and thus
      calling zil_replaying() is necessary for correctness.
      
      For ZVOLs the question of correctness is more nuanced: ZVOL logs only
      TX_WRITE and TX_TRUNCATE, both of which are idempotent. Logical
      dependencies between two records exist only if the write or discard
      request had sync semantics or if the ranges affected by the records
      overlap.
      
      Thus, at a first glance, it would be correct to restart replay from
      the beginning if we crash before replay completes. But this does not
      address the following scenario:
      Assume one log record per LWB.
      The chain on disk is
      
          HDR -> 1:W(1, "A") -> 2:W(1, "B") -> 3:W(2, "X") -> 4:W(3, "Z")
      
      where N:W(O, C) represents log entry number N which is a TX_WRITE of C
      to offset A.
      We replay 1, 2 and 3 in one txg, sync that txg, then crash.
      Bit flips corrupt 2, 3, and 4.
      We come up again and restart replay from the beginning because
      we did not call zil_replaying() during replay.
      We replay 1 again, then interpret 2's invalid checksum as the end
      of the ZIL chain and call replay done.
      The replayed zvol content is "AX".
      
      If we had called zil_replaying() the HDR would have pointed to 3
      and our resumed replay would not have replayed anything because
      3 was corrupted, resulting in zvol content "BX".
      
      If 3 logically depends on 2 then the replay corrupted the ZVOL_OBJ's
      contents.
      
      This patch adds the zil_replaying() calls to the replay functions.
      Since the callbacks in the replay function need the zilog_t* pointer
      so that they can call zil_replaying() we open the ZIL while
      replaying in zvol_create_minor(). We also verify that replay has
      been done when on-demand-opening the ZIL on the first modifying
      bio.
      Reviewed-by: default avatarMatthew Ahrens <mahrens@delphix.com>
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Signed-off-by: default avatarChristian Schwarz <me@cschwarz.com>
      Closes #11667 
      93e36580
    • Ryan Moeller's avatar
      ZTS: Improve cleanup in zpool tests · b30cd705
      Ryan Moeller authored
      
      * Restore original kern.corefile value after the test.
      * Don't leave behind a frozen pool.
      * Clean up leftover vdev files.
      * Make zpool_002_pos and zpool_003_pos consistent in their handling of
      core files while here.
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Signed-off-by: default avatarRyan Moeller <ryan@iXsystems.com>
      Closes #11694 
      b30cd705
    • manfromafar's avatar
      Clarify compressed zfs send/recv behavior · ecc277cf
      manfromafar authored
      
      Docs for send and receive do not explain behavior when sending a 
      compressed stream then receiving on a host that overrides compression 
      with -o compress=value.
      
      The data from the send stream is written as it was from the send is 
      the compressed form but the compression algorithm set on the receiver 
      is the overridden version which causes some confusion as to what 
      algorithm was actually used.
      
      Updated man docs to clarify behavior
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Reviewed By: Allan Jude <allanjude@freebsd.org>
      Signed-off-by: default avatarmanfromafar <manfromafar@outlook.com>
      Closes #11690 
      ecc277cf
    • Ryan Moeller's avatar
      Intentionally allow ZFS_READONLY in zfs_write · 4b2e2082
      Ryan Moeller authored
      
      ZFS_READONLY represents the "DOS R/O" attribute.
      When that flag is set, we should behave as if write access
      were not granted by anything in the ACL.  In particular:
      We _must_ allow writes after opening the file r/w, then
      setting the DOS R/O attribute, and writing some more.
      (Similar to how you can write after fchmod(fd, 0444).)
      
      Restore these semantics which were lost on FreeBSD when refactoring
      zfs_write.  To my knowledge Linux does not actually expose this flag,
      but we'll need it to eventually so I've added the supporting checks.
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Signed-off-by: default avatarRyan Moeller <ryan@iXsystems.com>
      Closes #11693 
      4b2e2082
  4. 06 Mar, 2021 1 commit
    • Brian Behlendorf's avatar
      Suppress cppcheck invalidSyntax warninigs · e7a06356
      Brian Behlendorf authored
      
      For some reason cppcheck 1.90 is generating an invalidSyntax warning
      when the BF64_SET macro is used in the zstream source.  The same
      warning is not reported by cppcheck 2.3, nor is their any evident
      problem with the expanded macro.  This appears to be an issue with
      this version of cppcheck.  This commit annotates the source to suppress
      the warning.
      Signed-off-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Closes #11700 
      e7a06356
  5. 05 Mar, 2021 4 commits
  6. 03 Mar, 2021 3 commits
  7. 02 Mar, 2021 1 commit
  8. 28 Feb, 2021 3 commits
  9. 24 Feb, 2021 10 commits
  10. 21 Feb, 2021 4 commits