- 27 7月, 2010 1 次提交
-
-
由 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>
-
- 28 7月, 2008 1 次提交
-
-
由 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>
-
- 14 2月, 2008 1 次提交
-
-
由 Marcin Slusarz 提交于
remove beX_add functions and replace all uses with beX_add_cpu Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Cc: Mark Fasheh <mark.fasheh@oracle.com> Reviewed-by: NDave Chinner <dgc@sgi.com> Cc: Timothy Shimmin <tes@sgi.com> Cc: <linux-ext4@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 15 10月, 2007 1 次提交
-
-
由 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>
-
- 14 7月, 2007 1 次提交
-
-
由 Christoph Hellwig 提交于
SGI-PV: 966505 SGI-Modid: xfs-linux-melb:xfs-kern:28947a Signed-off-by: NChristoph Hellwig <hch@infradead.org> Signed-off-by: NDavid Chinner <dgc@sgi.com> Signed-off-by: NTim Shimmin <tes@sgi.com>
-
- 08 5月, 2007 1 次提交
-
-
由 Eric Sandeen 提交于
Patch provided by Eric Sandeen. SGI-PV: 961694 SGI-Modid: xfs-linux-melb:xfs-kern:28204a Signed-off-by: NEric Sandeen <sandeen@sandeen.net> Signed-off-by: NLachlan McIlroy <lachlan@sgi.com> Signed-off-by: NTim Shimmin <tes@sgi.com>
-
- 20 6月, 2006 1 次提交
-
-
由 Nathan Scott 提交于
pure bloat. SGI-PV: 952969 SGI-Modid: xfs-linux-melb:xfs-kern:26251a Signed-off-by: NNathan Scott <nathans@sgi.com>
-
- 09 6月, 2006 1 次提交
-
-
由 Christoph Hellwig 提交于
SGI-PV: 943272 SGI-Modid: xfs-linux-melb:xfs-kern:25806a Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NNathan Scott <nathans@sgi.com>
-
- 17 3月, 2006 6 次提交
-
-
由 Nathan Scott 提交于
SGI-PV: 943272 SGI-Modid: xfs-linux-melb:xfs-kern:25494a Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NNathan Scott <nathans@sgi.com>
-
由 Nathan Scott 提交于
SGI-PV: 943272 SGI-Modid: xfs-linux-melb:xfs-kern:25493a Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NNathan Scott <nathans@sgi.com>
-
由 Nathan Scott 提交于
SGI-PV: 943272 SGI-Modid: xfs-linux-melb:xfs-kern:25491a Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NNathan Scott <nathans@sgi.com>
-
由 Nathan Scott 提交于
SGI-PV: 943272 SGI-Modid: xfs-linux-melb:xfs-kern:25490a Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NNathan Scott <nathans@sgi.com>
-
由 Nathan Scott 提交于
SGI-PV: 943272 SGI-Modid: xfs-linux-melb:xfs-kern:25489a Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NNathan Scott <nathans@sgi.com>
-
由 Nathan Scott 提交于
SGI-PV: 943272 SGI-Modid: xfs-linux-melb:xfs-kern:25484a Signed-off-by: NNathan Scott <nathans@sgi.com>
-
- 02 11月, 2005 2 次提交
-
-
由 Nathan Scott 提交于
boilerplate. SGI-PV: 913862 SGI-Modid: xfs-linux:xfs-kern:23903a Signed-off-by: NNathan Scott <nathans@sgi.com>
-
由 Nathan Scott 提交于
SGI-PV: 943122 SGI-Modid: xfs-linux:xfs-kern:23901a Signed-off-by: NNathan Scott <nathans@sgi.com>
-
- 21 6月, 2005 1 次提交
-
-
由 Christoph Hellwig 提交于
SGI-PV: 936255 SGI-Modid: xfs-linux:xfs-kern:192760a Signed-off-by: NChristoph Hellwig <hch@sgi.com> Signed-off-by: NNathan Scott <nathans@sgi.com>
-
- 17 4月, 2005 1 次提交
-
-
由 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!
-