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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux