On Wed, Mar 22, 2023 at 10:15:30AM +0800, Yu Kuai wrote: > Hi, > > 在 2023/03/22 10:02, Yu Kuai 写道: > > Hi, > > > > 在 2023/03/22 9:34, Ming Lei 写道: > > > On Wed, Mar 22, 2023 at 09:26:07AM +0800, Yu Kuai wrote: > > > > Hi, > > > > > > > > 在 2023/03/21 19:43, Ming Lei 写道: > > > > > On Fri, Feb 17, 2023 at 10:21:58AM +0800, Yu Kuai wrote: > > > > > > From: Yu Kuai <yukuai3@xxxxxxxxxx> > > > > > > > > > > > > Changes from RFC: > > > > > > - remove the patch to factor out GD_NEED_PART_SCAN > > > > > > > > > > > > Yu Kuai (2): > > > > > > block: Revert "block: Do not reread partition table on exclusively > > > > > > open device" > > > > > > block: fix scan partition for exclusively open device again > > > > > > > > > > Hi Yu kuai, > > > > > > > > > > Looks the original issue starts to re-appear now with the two patches: > > > > > > > > > > https://lore.kernel.org/linux-block/20221130135344.2ul4cyfstfs3znxg@quack3/ > > > > > > > > > > > > > > > And underlying disk partition and raid partition can be observed at the > > > > > same time. > > > > > > > > > > Can you take a look? > > > > Yes, thanks for the report. I realize that sda1 adn sdb1 is created > > > > while raid open sda and sdb excl, and I think this problem should exist > > > > before this patchset. > > > > > > Looks not reproduced before applying your two patches, that is > > > exactly what Jan > > > tried to fix with 36369f46e917 ("block: Do not reread partition > > > table on exclusively open device"). > > > > Hi, Ming > > > > I just tried your test with this patchset reverted, and I can still > > reporduce the problem myself. > > Oops, I forgot to revert the first patch. It's right the problem can't > be reporduced. > > > > raid only open this device excl, and disk_scan_partitions is not called: > > > > md_import_device > > blkdev_get_by_devo > > > > I need to add some debuginfo to figure out how GD_NEED_PART_SCAN is set > > for sda after raid is stopped. And this should explain why sda1 is > > created. > > I found how GD_NEED_PART_SCAN is set now, in patch 2, this is set before > bd_prepare_to_claim, so preciously faild part scan will still set this > bit, and following patch shold fix this problem: Just run quick test, the issue won't be reproduced with your patch, and the change looks rational too, Reviewed-by: Ming Lei <ming.lei@xxxxxxxxxx> Thanks, Ming
