1. 20 6月, 2017 3 次提交
  2. 26 5月, 2017 1 次提交
  3. 04 5月, 2017 1 次提交
  4. 04 4月, 2017 1 次提交
  5. 03 2月, 2017 1 次提交
  6. 31 1月, 2017 3 次提交
  7. 05 12月, 2016 1 次提交
  8. 20 10月, 2016 1 次提交
  9. 04 10月, 2016 2 次提交
  10. 19 9月, 2016 3 次提交
  11. 26 8月, 2016 3 次提交
  12. 03 8月, 2016 12 次提交
  13. 20 7月, 2016 1 次提交
  14. 21 6月, 2016 1 次提交
    • D
      xfs: refactor btree maxlevels computation · 19b54ee6
      Darrick J. Wong 提交于
      Create a common function to calculate the maximum height of a per-AG
      btree.  This will eventually be used by the rmapbt and refcountbt
      code to calculate appropriate maxlevels values for each.  This is
      important because the verifiers and the transaction block
      reservations depend on accurate estimates of how many blocks are
      needed to satisfy a btree split.
      
      We were mistakenly using the max bnobt height for all the btrees,
      which creates a dangerous situation since the larger records and
      keys in an rmapbt make it very possible that the rmapbt will be
      taller than the bnobt and so we can run out of transaction block
      reservation.
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      
      19b54ee6
  15. 08 2月, 2016 3 次提交
  16. 04 1月, 2016 1 次提交
  17. 12 10月, 2015 2 次提交
    • G
      libxfs: fix two comment typos · fef4ded8
      Geliang Tang 提交于
      Just fix two typos in code comments.
      Signed-off-by: NGeliang Tang <geliangtang@163.com>
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      fef4ded8
    • B
      xfs: validate metadata LSNs against log on v5 superblocks · a45086e2
      Brian Foster 提交于
      Since the onset of v5 superblocks, the LSN of the last modification has
      been included in a variety of on-disk data structures. This LSN is used
      to provide log recovery ordering guarantees (e.g., to ensure an older
      log recovery item is not replayed over a newer target data structure).
      
      While this works correctly from the point a filesystem is formatted and
      mounted, userspace tools have some problematic behaviors that defeat
      this mechanism. For example, xfs_repair historically zeroes out the log
      unconditionally (regardless of whether corruption is detected). If this
      occurs, the LSN of the filesystem is reset and the log is now in a
      problematic state with respect to on-disk metadata structures that might
      have a larger LSN. Until either the log catches up to the highest
      previously used metadata LSN or each affected data structure is modified
      and written out without incident (which resets the metadata LSN), log
      recovery is susceptible to filesystem corruption.
      
      This problem is ultimately addressed and repaired in the associated
      userspace tools. The kernel is still responsible to detect the problem
      and notify the user that something is wrong. Check the superblock LSN at
      mount time and fail the mount if it is invalid. From that point on,
      trigger verifier failure on any metadata I/O where an invalid LSN is
      detected. This results in a filesystem shutdown and guarantees that we
      do not log metadata changes with invalid LSNs on disk. Since this is a
      known issue with a known recovery path, present a warning to instruct
      the user how to recover.
      Signed-off-by: NBrian Foster <bfoster@redhat.com>
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      a45086e2