1. 01 Jan, 2024 1 commit
    • Umer Saleem's avatar
      Test for clone, mmap and write for block cloning · b84c67d6
      Umer Saleem authored
      
      For block cloning, if we mmap the cloned file and write from the
      map into the file, it triggers a panic in dbuf_redirty() on Linux.
      
      The same scenario causes data corruption on FreeBSD. Both these
      issues are fixed under PR#15656 and PR#15665.
      
      It would be good to add a test for this scenario in ZTS. The test
      program and issue was produced by @robn.
      Signed-off-by: default avatarUmer Saleem <usaleem@ixsystems.com>
      b84c67d6
  2. 27 Dec, 2023 1 commit
  3. 26 Dec, 2023 1 commit
  4. 21 Dec, 2023 4 commits
  5. 20 Dec, 2023 5 commits
  6. 15 Dec, 2023 2 commits
    • Umer Saleem's avatar
      Test LWB buffer overflow for block cloning · dbda4516
      Umer Saleem authored
      
      PR#15634 removes 128K into 2x68K LWB split optimization, since it
      was found to cause LWB buffer overflow while trying to write 128KB
      TX_CLONE_RANGE record with 1022 block pointers into 68KB buffer,
      with multiple VDEVs ZIL.
      
      This commit adds a test for this particular scenario by writing
      maximum sizes TX_CLONE_RANE record with 1022 block pointers into
      68KB buffer, with two SLOG devices.
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Reviewed-by: default avatarAlexander Motin <mav@FreeBSD.org>
      Reviewed-by: default avatarAmeer Hamza <ahamza@ixsystems.com>
      Signed-off-by: default avatarUmer Saleem <usaleem@ixsystems.com>
      Closes #15672 
      dbda4516
    • Alexander Motin's avatar
      dmu: Allow buffer fills to fail · 9b1677fb
      Alexander Motin authored
      
      When ZFS overwrites a whole block, it does not bother to read the
      old content from disk. It is a good optimization, but if the buffer
      fill fails due to page fault or something else, the buffer ends up
      corrupted, neither keeping old content, nor getting the new one.
      
      On FreeBSD this is additionally complicated by page faults being
      blocked by VFS layer, always returning EFAULT on attempt to write
      from mmap()'ed but not yet cached address range.  Normally it is
      not a big problem, since after original failure VFS will retry the
      write after reading the required data.  The problem becomes worse
      in specific case when somebody tries to write into a file its own
      mmap()'ed content from the same location.  In that situation the
      only copy of the data is getting corrupted on the page fault and
      the following retries only fixate the status quo.  Block cloning
      makes this issue easier to reproduce, since it does not read the
      old data, unlike traditional file copy, that may work by chance.
      
      This patch provides the fill status to dmu_buf_fill_done(), that
      in case of error can destroy the corrupted buffer as if no write
      happened.  One more complication in case of block cloning is that
      if error is possible during fill, dmu_buf_will_fill() must read
      the data via fall-back to dmu_buf_will_dirty().  It is required
      to allow in case of error restoring the buffer to a state after
      the cloning, not not before it, that would happen if we just call
      dbuf_undirty().
      Reviewed-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Reviewed-by: default avatarRob Norris <robn@despairlabs.com>
      Signed-off-by: default avatarAlexander Motin <mav@FreeBSD.org>
      Sponsored by: iXsystems, Inc.
      Closes #15665 
      9b1677fb
  7. 12 Dec, 2023 3 commits
  8. 11 Dec, 2023 3 commits
  9. 09 Dec, 2023 5 commits
  10. 07 Dec, 2023 4 commits
  11. 06 Dec, 2023 4 commits
  12. 05 Dec, 2023 5 commits
  13. 01 Dec, 2023 2 commits