1. 02 9月, 2017 2 次提交
  2. 23 8月, 2017 1 次提交
    • C
      xfs: stop searching for free slots in an inode chunk when there are none · 2d32311c
      Carlos Maiolino 提交于
      In a filesystem without finobt, the Space manager selects an AG to alloc a new
      inode, where xfs_dialloc_ag_inobt() will search the AG for the free slot chunk.
      
      When the new inode is in the same AG as its parent, the btree will be searched
      starting on the parent's record, and then retried from the top if no slot is
      available beyond the parent's record.
      
      To exit this loop though, xfs_dialloc_ag_inobt() relies on the fact that the
      btree must have a free slot available, once its callers relied on the
      agi->freecount when deciding how/where to allocate this new inode.
      
      In the case when the agi->freecount is corrupted, showing available inodes in an
      AG, when in fact there is none, this becomes an infinite loop.
      
      Add a way to stop the loop when a free slot is not found in the btree, making
      the function to fall into the whole AG scan which will then, be able to detect
      the corruption and shut the filesystem down.
      
      As pointed by Brian, this might impact performance, giving the fact we
      don't reset the search distance anymore when we reach the end of the
      tree, giving it fewer tries before falling back to the whole AG search, but
      it will only affect searches that start within 10 records to the end of the tree.
      Signed-off-by: NCarlos Maiolino <cmaiolino@redhat.com>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      2d32311c
  3. 12 8月, 2017 1 次提交
    • O
      xfs: fix inobt inode allocation search optimization · c44245b3
      Omar Sandoval 提交于
      When we try to allocate a free inode by searching the inobt, we try to
      find the inode nearest the parent inode by searching chunks both left
      and right of the chunk containing the parent. As an optimization, we
      cache the leftmost and rightmost records that we previously searched; if
      we do another allocation with the same parent inode, we'll pick up the
      search where it last left off.
      
      There's a bug in the case where we found a free inode to the left of the
      parent's chunk: we need to update the cached left and right records, but
      because we already reassigned the right record to point to the left, we
      end up assigning the left record to both the cached left and right
      records.
      
      This isn't a correctness problem strictly, but it can result in the next
      allocation rechecking chunks unnecessarily or allocating inodes further
      away from the parent than it needs to. Fix it by swapping the record
      pointer after we update the cached left and right records.
      
      Fixes: bd169565 ("xfs: speed up free inode search")
      Signed-off-by: NOmar Sandoval <osandov@fb.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      c44245b3
  4. 26 7月, 2017 1 次提交
  5. 25 7月, 2017 1 次提交
  6. 21 7月, 2017 3 次提交
  7. 14 7月, 2017 2 次提交
  8. 08 7月, 2017 1 次提交
    • D
      xfs: don't crash on unexpected holes in dir/attr btrees · cd87d867
      Darrick J. Wong 提交于
      In quite a few places we call xfs_da_read_buf with a mappedbno that we
      don't control, then assume that the function passes back either an error
      code or a buffer pointer.  Unfortunately, if mappedbno == -2 and bno
      maps to a hole, we get a return code of zero and a NULL buffer, which
      means that we crash if we actually try to use that buffer pointer.  This
      happens immediately when we set the buffer type for transaction context.
      
      Therefore, check that we have no error code and a non-NULL bp before
      trying to use bp.  This patch is a follow-up to an incomplete fix in
      96a3aefb ("xfs: don't crash if reading a directory results in an
      unexpected hole").
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      cd87d867
  9. 07 7月, 2017 1 次提交
    • D
      xfs: rename MAXPATHLEN to XFS_SYMLINK_MAXLEN · 6eb0b8df
      Darrick J. Wong 提交于
      XFS has a maximum symlink target length of 1024 bytes; this is a
      holdover from the Irix days.  Unfortunately, the constant establishing
      this is 'MAXPATHLEN' and is /not/ the same as the Linux MAXPATHLEN,
      which is 4096.
      
      The kernel enforces its 1024 byte MAXPATHLEN on symlink targets, but
      xfsprogs picks up the (Linux) system 4096 byte MAXPATHLEN, which means
      that xfs_repair doesn't complain about oversized symlinks.
      
      Since this is an on-disk format constraint, put the define in the XFS
      namespace and move everything over to use the new name.
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      6eb0b8df
  10. 28 6月, 2017 2 次提交
  11. 21 6月, 2017 3 次提交
  12. 20 6月, 2017 6 次提交
  13. 19 6月, 2017 2 次提交
  14. 26 5月, 2017 1 次提交
  15. 19 5月, 2017 1 次提交
  16. 17 5月, 2017 2 次提交
    • D
      xfs: fix warnings about unused stack variables · 6e747506
      Darrick J. Wong 提交于
      Reduce stack usage and get rid of compiler warnings by eliminating
      unused variables.
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NCarlos Maiolino <cmaiolino@redhat.com>
      6e747506
    • B
      xfs: fix indlen accounting error on partial delalloc conversion · 0daaecac
      Brian Foster 提交于
      The delalloc -> real block conversion path uses an incorrect
      calculation in the case where the middle part of a delalloc extent
      is being converted. This is documented as a rare situation because
      XFS generally attempts to maximize contiguity by converting as much
      of a delalloc extent as possible.
      
      If this situation does occur, the indlen reservation for the two new
      delalloc extents left behind by the conversion of the middle range
      is calculated and compared with the original reservation. If more
      blocks are required, the delta is allocated from the global block
      pool. This delta value can be characterized as the difference
      between the new total requirement (temp + temp2) and the currently
      available reservation minus those blocks that have already been
      allocated (startblockval(PREV.br_startblock) - allocated).
      
      The problem is that the current code does not account for previously
      allocated blocks correctly. It subtracts the current allocation
      count from the (new - old) delta rather than the old indlen
      reservation. This means that more indlen blocks than have been
      allocated end up stashed in the remaining extents and free space
      accounting is broken as a result.
      
      Fix up the calculation to subtract the allocated block count from
      the original extent indlen and thus correctly allocate the
      reservation delta based on the difference between the new total
      requirement and the unused blocks from the original reservation.
      Also remove a bogus assert that contradicts the fact that the new
      indlen reservation can be larger than the original indlen
      reservation.
      Signed-off-by: NBrian Foster <bfoster@redhat.com>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      0daaecac
  17. 04 5月, 2017 2 次提交
  18. 26 4月, 2017 8 次提交