Re: fsverity PAGE_SIZE constraints

["Chris Mason" <clm@fb.com>]

On 2 Jun 2020, at 17:50, Eric Biggers wrote:

> On Tue, Jun 02, 2020 at 11:49:36AM -0400, Chris Mason wrote:
>> On the btrfs side, I’m storing the fsverity data in the btree, so 
>> I’m merkle
>> block size agnostic.  Since our rollout is going to be x86, we’ll 
>> end up
>> using the 4k size internally for the current code base.
>>
>> My recommendation to simplify the merkle tree code would be to just 
>> put it
>> in slab objects instead pages and leverage recent MM changes to make 
>> reclaim
>> work well.  There’s probably still more to do on that front, but 
>> it’s a long
>> standing todo item for Josef to shift the btrfs metadata out of the 
>> page
>> cache, where we have exactly the same problems for exactly the same 
>> reasons.
>
> Do you have an idea for how to do that without introducing much extra 
> overhead
> to ext4 and f2fs with Merkle tree block size == PAGE_SIZE?  Currently 
> they just
> cache the Merkle tree pages in the inode's page cache.  We don't 
> *have* to do it
> that way, but anything that adds additional overhead (e.g. reading 
> data into
> pagecache, then copying it into slab allocations, then freeing the 
> pagecache
> pages) would be undesirable.  We need to keep the overhead minimal.

You can do the IO directly into the slab pages, so there won’t be 
extra copies, but there would be some extra code for ext4/f2fs because 
you’ve been reusing the existing readpages machinery.  I’d start 
with the copies into slab just because all the complexity is in reclaim, 
and adding FS helpers for file IO into specific pages is pretty well 
understood.

Slab reclaim is a little clunky in comparison to the page cache.  But, 
it does give you the chance to do merkle aware reclaim, pitching the 
blocks that are the least expensive to reread from an CPU/IO POV.  It 
also gives you the chance to strongly prefer not pitching any merkle 
pages at all, which might be useful to help limit the cost of thrashing 
in low memory situations.

-chris