On Wed, Mar 20, 2024 at 07:12:36PM -0700, Darrick J. Wong wrote: > On Tue, Mar 19, 2024 at 02:41:27PM -0700, Christoph Hellwig wrote: > > On Tue, Mar 19, 2024 at 02:38:27PM -0700, Darrick J. Wong wrote: > > > 64k is the maximum xattr value size, yes. But remote xattr value blocks > > > now have block headers complete with owner/uuid/magic/etc. Each block > > > can only store $blksz-56 bytes now. Hence that 64k value needs > > > ceil(65536 / 4040) == 17 blocks on a 4k fsb filesystem. > > > > Uggg, ok. I thought we'd just treat remote xattrs as data and don't > > add headers. That almost asks for using vmalloc if the size is just > > above a a power of two. > > > > > Same reason. Merkle tree blocks are $blksz by default, but storing a > > > 4096 blob in the xattrs requires ceil(4096 / 4040) == 2 blocks. Most of > > > that second block is wasted. > > > > *sad panda face*. We should be able to come up with something > > better than that.. > > Well xfs_verity.c could just zlib/zstd/whatever compress the contents > and see if that helps. We only need a ~2% compression to shrink to a > single 4k block, a ~1% reduction for 64k blocks, or a 6% reduction for > 1k blocks. ...or we just turn off the attr remote header for XFS_ATTR_VERITY merkle tree block values and XOR i_ino, merkle_pos, and the fs uuid into the first 32 bytes. --D > --D >
