linux-kernel - Re: [00/17] Large Blocksize Support V3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Apr 2007 01:48:49 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	David Chinner <dgc@....com>
Cc:	clameter@....com, linux-kernel@...r.kernel.org,
	Mel Gorman <mel@...net.ie>,
	William Lee Irwin III <wli@...omorphy.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	Badari Pulavarty <pbadari@...il.com>,
	Maxim Levitsky <maximlevitsky@...il.com>
Subject: Re: [00/17] Large Blocksize Support V3

On Fri, 27 Apr 2007 18:03:21 +1000 David Chinner <dgc@....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?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/