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 upusing 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 pagecachepages) 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
|