1. 01 5月, 2019 1 次提交
  2. 19 12月, 2018 1 次提交
  3. 12 12月, 2018 1 次提交
  4. 17 11月, 2018 1 次提交
  5. 09 11月, 2018 1 次提交
    • A
      gfs2: Fix metadata read-ahead during truncate (2) · e7445ced
      Andreas Gruenbacher 提交于
      The previous attempt to fix for metadata read-ahead during truncate was
      incorrect: for files with a height > 2 (1006989312 bytes with a block
      size of 4096 bytes), read-ahead requests were not being issued for some
      of the indirect blocks discovered while walking the metadata tree,
      leading to significant slow-downs when deleting large files.  Fix that.
      
      In addition, only issue read-ahead requests in the first pass through
      the meta-data tree, while deallocating data blocks.
      
      Fixes: c3ce5aa9 ("gfs2: Fix metadata read-ahead during truncate")
      Cc: stable@vger.kernel.org # v4.16+
      Signed-off-by: NAndreas Gruenbacher <agruenba@redhat.com>
      e7445ced
  6. 12 10月, 2018 2 次提交
  7. 10 10月, 2018 1 次提交
  8. 26 7月, 2018 1 次提交
    • A
      gfs2: Special-case rindex for gfs2_grow · 77612578
      Andreas Gruenbacher 提交于
      To speed up the common case of appending to a file,
      gfs2_write_alloc_required presumes that writing beyond the end of a file
      will always require additional blocks to be allocated.  This assumption
      is incorrect for preallocates files, but there are no negative
      consequences as long as *some* space is still left on the filesystem.
      
      One special file that always has some space preallocated beyond the end
      of the file is the rindex: when growing a filesystem, gfs2_grow adds one
      or more new resource groups and appends records describing those
      resource groups to the rindex; the preallocated space ensures that this
      is always possible.
      
      However, when a filesystem is completely full, gfs2_write_alloc_required
      will indicate that an additional allocation is required, and appending
      the next record to the rindex will fail even though space for that
      record has already been preallocated.  To fix that, skip the incorrect
      optimization in gfs2_write_alloc_required, but for the rindex only.
      Other writes to preallocated space beyond the end of the file are still
      allowed to fail on completely full filesystems.
      Signed-off-by: NAndreas Gruenbacher <agruenba@redhat.com>
      Reviewed-by: NBob Peterson <rpeterso@redhat.com>
      77612578
  9. 02 7月, 2018 4 次提交
  10. 21 6月, 2018 1 次提交
  11. 04 6月, 2018 4 次提交
  12. 02 6月, 2018 2 次提交
  13. 17 4月, 2018 1 次提交
    • A
      gfs2: Remove sdp->sd_jheightsize · 9a38662b
      Andreas Gruenbacher 提交于
      GFS2 keeps two arrarys in the superblock that define the maximum size of
      an inode depending on the inode's height: sdp->sd_heightsize defines the
      heights in units of sb->s_blocksize; sdp->sd_jheightsize defines them in
      units of sb->s_blocksize - sizeof(struct gfs2_meta_header).  These
      arrays are used to determine when additional layers of indirect blocks
      are needed.  The second array is used for directories which have an
      additional gfs2_meta_header at the beginning of each block.
      
      Distinguishing between these two cases makes no sense: the height
      required for representing N blocks will come out the same no matter if
      the calculation is done in gross (sb->s_blocksize) or net
      (sb->s_blocksize - sizeof(struct gfs2_meta_header)) units.
      
      Stuffed directories don't have an additional gfs2_meta_header, but the
      stuffed case is handled separately for both files and directories,
      anyway.
      
      Remove the unncessary sdp->sd_jheightsize array.
      Signed-off-by: NAndreas Gruenbacher <agruenba@redhat.com>
      Signed-off-by: NBob Peterson <rpeterso@redhat.com>
      9a38662b
  14. 13 4月, 2018 1 次提交
  15. 29 3月, 2018 1 次提交
  16. 24 3月, 2018 1 次提交
    • A
      gfs2: Check for the end of metadata in punch_hole · bb491ce6
      Andreas Gruenbacher 提交于
      When punching a hole or truncating an inode down to a given size, also
      check if the truncate point / start of the hole is within the range we
      have metadata for.  Otherwise, we can end up freeing blocks that
      shouldn't be freed, corrupting the inode, or crashing the machine when
      trying to punch a hole into the void.
      
      When growing an inode via truncate, we set the new size but we don't
      allocate additional levels of indirect blocks and grow the inode height.
      When shrinking that inode again, the new size may still point beyond the
      end of the inode's metadata.
      
      Fixes xfstest generic/476.
      Debugged-by: NBob Peterson <rpeterso@redhat.com>
      Signed-off-by: NAndreas Gruenbacher <agruenba@redhat.com>
      Signed-off-by: NBob Peterson <rpeterso@redhat.com>
      bb491ce6
  17. 09 3月, 2018 1 次提交
  18. 08 3月, 2018 1 次提交
  19. 14 2月, 2018 1 次提交
    • A
      gfs2: Fixes to "Implement iomap for block_map" · 49edd5bf
      Andreas Gruenbacher 提交于
      It turns out that commit 3974320c "Implement iomap for block_map"
      introduced a few bugs that trigger occasional failures with xfstest
      generic/476:
      
      In gfs2_iomap_begin, we jump to do_alloc when we determine that we are
      beyond the end of the allocated metadata (height > ip->i_height).
      There, we can end up calling hole_size with a metapath that doesn't
      match the current metadata tree, which doesn't make sense.  After
      untangling the code at do_alloc, fix this by checking if the block we
      are looking for is within the range of allocated metadata.
      
      In addition, add a BUG() in case gfs2_iomap_begin is accidentally called
      for reading stuffed files: this is handled separately.  Make sure we
      don't truncate iomap->length for reads beyond the end of the file; in
      that case, the entire range counts as a hole.
      
      Finally, revert to taking a bitmap write lock when doing allocations.
      It's unclear why that change didn't lead to any failures during testing.
      Signed-off-by: NAndreas Gruenbacher <agruenba@redhat.com>
      Signed-off-by: NBob Peterson <rpeterso@redhat.com>
      49edd5bf
  20. 19 1月, 2018 4 次提交
  21. 17 1月, 2018 8 次提交
  22. 31 10月, 2017 1 次提交