Re: [patch 00/14] Page cache cleanup in anticipation of LargeBlocksize support

[Christoph Lameter]

On Thu, 14 Jun 2007, Andrew Morton wrote:

> > The metadata needs to refer to 1/16th of the earlier pages that need to be 
> > tracked. metadata is shrunk significantly.
> 
> Only if the filesystems are altered to use larger blocksizes and if the
> operator then chooses to use that feature.  Then they suck for small-sized
> (and even medium-sized) files.

Nope. File systems already support that. The changes to XFS and ext2 are 
basically just doing the cleanups that we are discussing here plus some 
changes to set_blocksize.
 
> So you're still talking about corner cases: specialised applications which
> require careful setup and administrator intervention.
> 
> What can we do to optimise the common case?

The common filesystem will be able to support large block sizes easily. 
Most filesystems already run on 16k and 64k page size platforms and do 
just fine. All the work is already done. Just the VM needs to give them 
support for lager page sizes on smaller page size platforms.

This is optimizing the common case.

> The alleged fsck benefit is also unrelated to variable PAGE_CACHE_SIZE. 
> It's a feature of larger (unweildy?) blocksize, and xfs already has that
> working (doesn't it?)

It has a hack with severe limitations like we have done in many other 
components of the kernel. These hacks can be removed if the large 
blocksize support is merged. XFS still has the problem that the block 
layer without page cache support for higher pages cannot easily deal with 
large contiguous pages.

> There may be some benefits to some future version of ext4.

I have already run ext4 with 64k blocksize on x86_64 with 4k. It has been 
done for years with 64k page size on IA64 and powerpc and there is no fs 
issue with running it on 4k platforms with the large blocksize patchset.
The filesystems work reliably. The core linux code is the issue that we 
need to solve and this is the beginning of doing so.
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/