1. 17 8月, 2012 1 次提交
  2. 15 5月, 2012 3 次提交
  3. 28 3月, 2012 1 次提交
    • D
      xfs: fix fstrim offset calculations · a66d6363
      Dave Chinner 提交于
      xfs_ioc_fstrim() doesn't treat the incoming offset and length
      correctly. It treats them as a filesystem block address, rather than
      a disk address. This is wrong because the range passed in is a
      linear representation, while the filesystem block address notation
      is a sparse representation. Hence we cannot convert the range direct
      to filesystem block units and then use that for calculating the
      range to trim.
      
      While this sounds dangerous, the problem is limited to calculating
      what AGs need to be trimmed. The code that calcuates the actual
      ranges to trim gets the right result (i.e. only ever discards free
      space), even though it uses the wrong ranges to limit what is
      trimmed. Hence this is not a bug that endangers user data.
      
      Fix this by treating the range as a disk address range and use the
      appropriate functions to convert the range into the desired formats
      for calculations.
      
      Further, fix the first free extent lookup (the longest) to actually
      find the largest free extent. Currently this lookup uses a <=
      lookup, which results in finding the extent to the left of the
      largest because we can never get an exact match on the largest
      extent. This is due to the fact that while we know it's size, we
      don't know it's location and so the exact match fails and we move
      one record to the left to get the next largest extent. Instead, use
      a >= search so that the lookup returns the largest extent regardless
      of the fact we don't get an exact match on it.
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NBen Myers <bpm@sgi.com>
      a66d6363
  4. 04 1月, 2012 1 次提交
  5. 12 10月, 2011 1 次提交
    • L
      xfs: fix possible overflow in xfs_ioc_trim() · c029a50d
      Lukas Czerner 提交于
      In xfs_ioc_trim it is possible that computing the last allocation group
      to discard might overflow for big start & len values, because the result
      might be bigger then xfs_agnumber_t which is 32 bit long. Fix this by not
      allowing the start and end block of the range to be beyond the end of the
      file system.
      
      Note that if the start is beyond the end of the file system we have to
      return -EINVAL, but in the "end" case we have to truncate it to the fs
      size.
      
      Also introduce "end" variable, rather than using start+len which which
      might be more confusing to get right as this bug shows.
      Signed-off-by: NLukas Czerner <lczerner@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAlex Elder <aelder@sgi.com>
      c029a50d
  6. 13 8月, 2011 1 次提交
    • C
      xfs: remove subdirectories · c59d87c4
      Christoph Hellwig 提交于
      Use the move from Linux 2.6 to Linux 3.x as an excuse to kill the
      annoying subdirectories in the XFS source code.  Besides the large
      amount of file rename the only changes are to the Makefile, a few
      files including headers with the subdirectory prefix, and the binary
      sysctl compat code that includes a header under fs/xfs/ from
      kernel/.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAlex Elder <aelder@sgi.com>
      c59d87c4
  7. 25 5月, 2011 1 次提交
    • C
      xfs: add online discard support · e84661aa
      Christoph Hellwig 提交于
      Now that we have reliably tracking of deleted extents in a
      transaction we can easily implement "online" discard support
      which calls blkdev_issue_discard once a transaction commits.
      
      The actual discard is a two stage operation as we first have
      to mark the busy extent as not available for reuse before we
      can start the actual discard.  Note that we don't bother
      supporting discard for the non-delaylog mode.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAlex Elder <aelder@sgi.com>
      e84661aa
  8. 23 2月, 2011 1 次提交
    • L
      xfs: check if device support discard in xfs_ioc_trim() · be715140
      Lukas Czerner 提交于
      Right now we, are relying on the fact that when we attempt to
      actually do the discard, blkdev_issue_discar() returns -EOPNOTSUPP
      and the user is informed that the device does not support discard.
      
      However, in the case where the we do not hit any suitable free
      extent to trim in FITRIM code, it will finish without any error.
      This is very confusing, because it seems that FITRIM was successful
      even though the device does not actually supports discard.
      
      Solution: Check for the discard support before attempt to search for
      free extents.
      Signed-off-by: NLukas Czerner <lczerner@redhat.com>
      Signed-off-by: NAlex Elder <aelder@sgi.com>
      be715140
  9. 22 2月, 2011 1 次提交
    • L
      xfs: check if device support discard in xfs_ioc_trim() · 5d157655
      Lukas Czerner 提交于
      Right now we, are relying on the fact that when we attempt to
      actually do the discard, blkdev_issue_discar() returns -EOPNOTSUPP
      and the user is informed that the device does not support discard.
      
      However, in the case where the we do not hit any suitable free
      extent to trim in FITRIM code, it will finish without any error.
      This is very confusing, because it seems that FITRIM was successful
      even though the device does not actually supports discard.
      
      Solution: Check for the discard support before attempt to search for
      free extents.
      Signed-off-by: NLukas Czerner <lczerner@redhat.com>
      Signed-off-by: NAlex Elder <aelder@sgi.com>
      5d157655
  10. 12 1月, 2011 1 次提交