Re: [00/17] Large Blocksize Support V3

Andrew Morton
2007-04-27T08:49:05Z

On Fri, 27 Apr 2007 18:03:21 +1000 David Chinner <dgc@sgi.com> wrote:

> > > > > You basically have to
> > > > > jump through nasty, nasty hoops, to handle corner cases that are introduced
> > > > > because the generic code can no longer reliably lock out access to a
> > > > > filesystem block.
> > >
> > > This way lies insanity.
> >
> > You're addressing Christoph's straw man here.
>
> No, I'm speaking from years of experience working on a
> page/buffer/chunk cache capable of using both large pages and
> aggregating multiple pages. It has, at times, almost driven me
> insane and I don't want to go back there.

We're talking about two separate things here - let us not conflate them.

1: The arguably-crippled HBA which wants bigger SG lists.

2: The late-breaking large-blocksizes-in-the-fs thing.

None of this multiple-page-locking stuff we're discussing here is relevant
to the HBA performance problem. It's pretty simple (I think) for us to
ensure that, for the great majority of the time, contiguous pages in a file
are also physically contiguous. Problem solved, HBA go nice and quick,
move on.

Now, we have this the second and completely unrelated requirement:
supporting fs-blocksize > PAGE_SIZE. One way to address this is via the
mangle-multiple-pages-into-one approach. And it's obviously the best way
to do it, if mangle-multiple-pages is already available.

But I don't know how important requirement 2 is. XFS already has
presumably-working private code to do it, and there is simplification and
perhaps modest performance gain in the block allocator to be had here.

And other filesystems (ie: ext4) _might_ use it. But ext4 is extent-based,
so perhaps it's not work churning the on-disk format to get a bit of a
boost in the block allocator.

So I _think_ what this boils down to is offering some simplifications in
XFS, by adding complexications to core VFS and MM. I dunno if that's a
good deal.

So... tell us why you want feature 2?