On Tue, Dec 13, 2022 at 12:50:28PM -0800, Eric Biggers wrote: > On Tue, Dec 13, 2022 at 06:29:24PM +0100, Andrey Albershteyn wrote: > > Not yet implemented: > > - No pre-fetching of Merkle tree pages in the > > read_merkle_tree_page() > > This would be helpful, but not essential. > > > - No marking of already verified Merkle tree pages (each read, the > > whole tree is verified). Ah, I wasn't aware that this was missing. > > This is essential to have, IMO. > > You *could* do what btrfs does, where it caches the Merkle tree pages in the > inode's page cache past i_size, even though btrfs stores the Merkle tree > separately from the file data on-disk. > > However, I'd guess that the other XFS developers would have an adversion to that > approach, even though it would not affect the on-disk storage. Yup, on an architectural level it just seems wrong to cache secure verification metadata in the same user accessible address space as the data it verifies. > The alternatives would be to create a separate in-memory-only inode for the > cache, or to build a custom cache with its own shrinker. The merkel tree blocks are cached in the XFS buffer cache. Andrey, could we just add a new flag to the xfs_buf->b_flags to indicate that the buffer contains verified merkle tree records? i.e. if it's not set after we've read the buffer, we need to verify the buffer and set th verified buffer in cache and we can skip the verification? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
