1. 03 Sep, 2010 3 commits
    • Alex Elder's avatar
    • Tao Ma's avatar
      xfs: Make fiemap work with sparse files · 9af25465
      Tao Ma authored
      In xfs_vn_fiemap, we set bvm_count to fi_extent_max + 1 and want
      to return fi_extent_max extents, but actually it won't work for
      a sparse file. The reason is that in xfs_getbmap we will
      calculate holes and set it in 'out', while out is malloced by
      bmv_count(fi_extent_max+1) which didn't consider holes. So in the
      worst case, if 'out' vector looks like
      [hole, extent, hole, extent, hole, ... hole, extent, hole],
      we will only return half of fi_extent_max extents.
      
      This patch add a new parameter BMV_IF_NO_HOLES for bvm_iflags.
      So with this flags, we don't use our 'out' in xfs_getbmap for
      a hole. The solution is a bit ugly by just don't increasing
      index of 'out' vector. I felt that it is not easy to skip it
      at the very beginning since we have the complicated check and
      some function like xfs_getbmapx_fix_eof_hole to adjust 'out'.
      
      Cc: Dave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarTao Ma <tao.ma@oracle.com>
      Signed-off-by: default avatarAlex Elder <aelder@sgi.com>
      9af25465
    • Dave Chinner's avatar
      xfs: prevent 32bit overflow in space reservation · 72656c46
      Dave Chinner authored
      If we attempt to preallocate more than 2^32 blocks of space in a
      single syscall, the transaction block reservation will overflow
      leading to a hangs in the superblock block accounting code. This
      is trivially reproduced with xfs_io. Fix the problem by capping the
      allocation reservation to the maximum number of blocks a single
      xfs_bmapi() call can allocate (2^21 blocks).
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      72656c46
  2. 02 Sep, 2010 2 commits
    • Arkadiusz Mi?kiewicz's avatar
      xfs: Disallow 32bit project quota id · 23963e54
      Arkadiusz Mi?kiewicz authored
      Currently on-disk structure is able to keep only 16bit project quota
      id, so disallow 32bit ones. This fixes a problem where parts of
      kernel structures holding project quota id are 32bit while parts
      (on-disk) are 16bit variables which causes project quota member
      files to be inaccessible for some operations (like mv/rm).
      Signed-off-by: default avatarArkadiusz Mi?kiewicz <arekm@maven.pl>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAlex Elder <aelder@sgi.com>
      23963e54
    • Dave Chinner's avatar
      xfs: improve buffer cache hash scalability · 9bc08a45
      Dave Chinner authored
      When doing large parallel file creates on a 16p machines, large amounts of
      time is being spent in _xfs_buf_find(). A system wide profile with perf top
      shows this:
      
                1134740.00 19.3% _xfs_buf_find
                 733142.00 12.5% __ticket_spin_lock
      
      The problem is that the hash contains 45,000 buffers, and the hash table width
      is only 256 buffers. That means we've got around 200 buffers per chain, and
      searching it is quite expensive. The hash table size needs to increase.
      
      Secondly, every time we do a lookup, we promote the buffer we find to the head
      of the hash chain. This is causing cachelines to be dirtied and causes
      invalidation of cachelines across all CPUs that may have walked the hash chain
      recently. hence every walk of the hash chain is effectively a cold cache walk.
      Remove the promotion to avoid this invalidation.
      
      The results are:
      
                1045043.00 21.2% __ticket_spin_lock
                 326184.00  6.6% _xfs_buf_find
      
      A 70% drop in the CPU usage when looking up buffers. Unfortunately that does
      not result in an increase in performance underthis workload as contention on
      the inode_lock soaks up most of the reduction in CPU usage.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      9bc08a45
  3. 29 Aug, 2010 3 commits
  4. 28 Aug, 2010 28 commits
  5. 27 Aug, 2010 4 commits