1. 27 7月, 2010 1 次提交
    • C
      xfs: drop dmapi hooks · 288699fe
      Christoph Hellwig 提交于
      Dmapi support was never merged upstream, but we still have a lot of hooks
      bloating XFS for it, all over the fast pathes of the filesystem.
      
      This patch drops over 700 lines of dmapi overhead.  If we'll ever get HSM
      support in mainline at least the namespace events can be done much saner
      in the VFS instead of the individual filesystem, so it's not like this
      is much help for future work.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      288699fe
  2. 28 7月, 2008 1 次提交
    • B
      [XFS] Name operation vector for hash and compare · 5163f95a
      Barry Naujok 提交于
      Adds two pieces of functionality for the basis of case-insensitive support
      in XFS:
      
      1. A comparison result enumerated type: xfs_dacmp. It represents an
      
      exact match, case-insensitive match or no match at all. This patch
      
      only implements different and exact results.
      
      2. xfs_nameops vector for specifying how to perform the hash generation
      
      of filenames and comparision methods. In this patch the hash vector
      
      points to the existing xfs_da_hashname function and the comparison
      
      method does a length compare, and if the same, does a memcmp and
      
      return the xfs_dacmp result.
      
      All filename functions that use the hash (create, lookup remove, rename,
      etc) now use the xfs_nameops.hashname function and all directory lookup
      functions also use the xfs_nameops.compname function.
      
      The lookup functions also handle case-insensitive results even though the
      default comparison function cannot return that. And important aspect of
      the lookup functions is that an exact match always has precedence over a
      case-insensitive. So while a case-insensitive match is found, we have to
      keep looking just in case there is an exact match. In the meantime, the
      info for the first case-insensitive match is retained if no exact match is
      found.
      
      SGI-PV: 981519
      SGI-Modid: xfs-linux-melb:xfs-kern:31205a
      Signed-off-by: NBarry Naujok <bnaujok@sgi.com>
      Signed-off-by: NChristoph Hellwig <hch@infradead.org>
      5163f95a
  3. 14 2月, 2008 1 次提交
  4. 15 10月, 2007 1 次提交
    • D
      [XFS] Radix tree based inode caching · da353b0d
      David Chinner 提交于
      One of the perpetual scaling problems XFS has is indexing it's incore
      inodes. We currently uses hashes and the default hash sizes chosen can
      only ever be a tradeoff between memory consumption and the maximum
      realistic size of the cache.
      
      As a result, anyone who has millions of inodes cached on a filesystem
      needs to tunes the size of the cache via the ihashsize mount option to
      allow decent scalability with inode cache operations.
      
      A further problem is the separate inode cluster hash, whose size is based
      on the ihashsize but is smaller, and so under certain conditions (sparse
      cluster cache population) this can become a limitation long before the
      inode hash is causing issues.
      
      The following patchset removes the inode hash and cluster hash and
      replaces them with radix trees to avoid the scalability limitations of the
      hashes. It also reduces the size of the inodes by 3 pointers....
      
      SGI-PV: 969561
      SGI-Modid: xfs-linux-melb:xfs-kern:29481a
      Signed-off-by: NDavid Chinner <dgc@sgi.com>
      Signed-off-by: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: NTim Shimmin <tes@sgi.com>
      da353b0d
  5. 14 7月, 2007 1 次提交
  6. 08 5月, 2007 1 次提交
  7. 20 6月, 2006 1 次提交
  8. 09 6月, 2006 1 次提交
  9. 17 3月, 2006 6 次提交
  10. 02 11月, 2005 2 次提交
  11. 21 6月, 2005 1 次提交
  12. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4