Re: [LSF/MM/BPF TOPIC] Cloud storage optimizations

From: Luis Chamberlain <mcgrof@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
	Keith Busch <kbusch@kernel.org>, Theodore Ts'o <tytso@mit.edu>,
	lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-block@vger.kernel.org
Subject: Re: [LSF/MM/BPF TOPIC] Cloud storage optimizations
Date: Sat, 4 Mar 2023 20:15:50 -0800	[thread overview]
Message-ID: <ZAQXduwAcAtIZHkB@bombadil.infradead.org> (raw)
In-Reply-To: <ZAN0JkklyCRIXVo6@casper.infradead.org>

On Sat, Mar 04, 2023 at 04:39:02PM +0000, Matthew Wilcox wrote:
> I'm getting more and more
> comfortable with the idea that "Linux doesn't support block sizes >
> PAGE_SIZE on 32-bit machines" is an acceptable answer.

First of all filesystems would need to add support for a larger block
sizes > PAGE_SIZE, and that takes effort. It is also a support question
too.

I think garnering consensus from filesystem developers we don't want
to support block sizes > PAGE_SIZE on 32-bit systems would be a good
thing to review at LSFMM or even on this list. I hightly doubt anyone
is interested in that support.

> XFS already works with arbitrary-order folios. 

But block sizes > PAGE_SIZE is work which is still not merged. It
*can* be with time. That would allow one to muck with larger block
sizes than 4k on x86-64 for instance. Without this, you can't play
ball.

> The only needed piece is
> specifying to the VFS that there's a minimum order for this particular
> inode, and having the VFS honour that everywhere.

Other than the above too, don't we still also need to figure out what
fs APIs would incur larger order folios? And then what about corner cases
with the page cache?

I was hoping some of these nooks and crannies could be explored with tmpfs.

  Luis