On Sun, Mar 05, 2023 at 05:02:43AM +0000, Matthew Wilcox wrote: > On Sat, Mar 04, 2023 at 08:15:50PM -0800, Luis Chamberlain wrote: > > On Sat, Mar 04, 2023 at 04:39:02PM +0000, Matthew Wilcox wrote: > > > 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. > > Do you mean that XFS is checking that fs block size <= PAGE_SIZE and > that check needs to be dropped? If so, I don't see where that happens. None of that. Back in 2018 Chinner had prototyped XFS support with larger block size > PAGE_SIZE: https://lwn.net/ml/linux-fsdevel/20181107063127.3902-1-david@xxxxxxxxxxxxx/ I just did a quick attempt to rebased it and most of the left over work is actually on IOMAP for writeback and zero / writes requiring a new zero-around functionality. All bugs on the rebase are my own, only compile tested so far, and not happy with some of the changes I had to make so likely could use tons more love: https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=20230307-larger-bs-then-ps-xfs But it should give you an idea of what type of things filesystems need to do. And so, each fs would need to decide if they want to support this sort of work. It is important from a support perspective, otherwise its hard to procure > 4 PAGE_SIZE systems. Luis
