> > > > > Another thing is waiting during reshape for metadata update on > MD_CHANGE_DEVS flag. > > To roll reshape I've added the following code (instead calling > md_ubdate_sb()): > > Yes, there is a real issue there... > > I don't think we ever need the kernel to wait for an external metadata > handler > to respond to device changes (apart from failure which is handled > separately). > So maybe the best thing is to guard all settings of MD_CHANGE_DEVS with > if (mddev->persistent) > > I think that would be best, but I've make a note to review that later. > Neil, from what I see in the raid5.c/md.c "native" code uses MD_CHANGE_DEVS during the reshape if it reaches special points when metadata write is really needed to update the reshape checkpoint. In reshape_request(): /* Cannot proceed until we've updated the superblock */ .. set_bit(MD_CHANGE_DEVS, mddev->flags) In md_check_recovery() we have: if (mddev->flags) md_update_sb() Couldn't we follow this logic with MD_CHANGE_DEVS for external metadata? If not, how to detect the need for migration checkpoint update? Thanks, Maciek -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
