On Wed, Jan 04, 2023 at 12:08:09PM +0530, Ojaswin Mujoo wrote: > Hi Eric, > > I have roughly gone through the series and run the (patched) xfstests on > this patchset on a powerpc machine with 64k pagesize and 64k,4k and 1k > merkle tree size on EXT4 and everything seems to work correctly. > > Just for records, test generic/692 takes a lot of time to complete with > 64k merkel tree size due to the calculations assuming it to be 4k, > however I was able to manually test that particular scenario. (I'll try > to send a patch to fix the fstest later). > > Anyways, feel free to add: > > Tested-by: Ojaswin Mujoo <ojaswin@xxxxxxxxxxxxx> > > Since I was not very familiar with the fsverty codebase, I'll try to > take some more time to review the code and get back with any > comments/RVBs. > > Regards, > ojaswin Thanks Ojaswin! That's a good point about generic/692. The right fix for it is to make it use $FSV_BLOCK_SIZE instead of 4K in its calculations. I suppose you saw that issue by running the test on ext4 with fs_block_size == page_size == 64K, causing xfstests to use merkle_tree_block_size == 64K by default. Thanks for doing that; that's something I haven't been able to test yet. My focus has been on merkle_tree_block_size < page_size. merkle_tree_block_size > 4K should just work, though, assuming merkle_tree_block_size <= min(fs_block_size, page_size). (Or merkle_tree_block_size == fs_block_size == page_size before this patch series.) - Eric
|