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

Christoph Lameter
2007-06-15T02:37:44Z

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.