On Nov 7, 2022, at 5:21 AM, Ritesh Harjani (IBM) <ritesh.list@xxxxxxxxx> wrote: > > This patch adds a test to verify the core bitmaps merge APIs > for rbtree bitmap type. > > Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@xxxxxxxxx> Reviewed-by: Andreas Dilger <adilger@xxxxxxxxx> > +/* > + * Note we use EXT2FS_BMAP64_BITARRAY always for used_bitmap, this is because > + * EXT2FS_BMAP64_RBTREE does not support parallel scan due to rcursor > + * optimization. > + */ Is this going to be a problem in the future? I think for pass1/pass5 there are no rbtree bitmaps that are *source* bitmaps for multi-threaded operation, but I suspect that once we try to parallelize pass2 this could break. Is there any check in the code that prevents multi-thread access to an rbtree bitmap? Making a copy for each thread, or ideally copying the rcursor for each thread, to allow at least multi-threaded reads. I don't think there is a high need for multi-threaded write Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
