On Wed, Dec 14, 2022 at 07:33:19AM +1100, Dave Chinner wrote: > On Tue, Dec 13, 2022 at 11:08:45AM -0800, Eric Biggers wrote: > > On Tue, Dec 13, 2022 at 06:29:34PM +0100, Andrey Albershteyn wrote: > > > > > > Also add check that block size == PAGE_SIZE as fs-verity doesn't > > > support different sizes yet. > > > > That's coming with > > https://lore.kernel.org/linux-fsdevel/20221028224539.171818-1-ebiggers@xxxxxxxxxx/T/#u, > > which I'll be resending soon and I hope to apply for 6.3. > > Review and testing of that patchset, along with its associated xfstests update > > (https://lore.kernel.org/fstests/20221211070704.341481-1-ebiggers@xxxxxxxxxx/T/#u), > > would be greatly appreciated. > > > > Note, as proposed there will still be a limit of: > > > > merkle_tree_block_size <= fs_block_size <= page_size > > > Hopefully you don't need fs_block_size > page_size or > > Yes, we will. > > This back on my radar now that folios have settled down. It's > pretty trivial for XFS to do because we already support metadata > block sizes > filesystem block size. Here is an old prototype: > > https://lore.kernel.org/linux-xfs/20181107063127.3902-1-david@xxxxxxxxxxxxx/ As per my follow-up response (https://lore.kernel.org/r/Y5jc7P1ZeWHiTKRF@sol.localdomain), I now think that wouldn't actually be a problem. > > merkle_tree_block_size > fs_block_size? > > That's also a desirable addition. > > XFS is using xattrs to hold merkle tree blocks so the merkle tree > storage is are already independent of the filesystem block size and > page cache limitations. Being able to using 64kB merkle tree blocks > would be really handy for reducing the search depth and overall IO > footprint of really large files. Well, the main problem is that using a Merkle tree block of 64K would mean that you can never read less than 64K at a time. - Eric
