On Tue, Dec 15, 2009 at 10:16 PM, Neil Brown <neilb@xxxxxxx> wrote: > I'm tempted to wait a bit longer and see if you find a solution, > as you seem to be progressing quite well :-) But I won't. > > I imagine there are two cases: > 1/ assembling an array from devices some of which might be partially > recovered, > 2/ re-adding a device to an array which is already active. > > In the first case, mdadm would: > - add the disk (write to new_dev) > - set the slot - this sets 'In_sync' > - set the recovery_start - this clears 'In_sync' as required. > > In the second case either mdadm or mdmon would: > - write 'frozen' to sync_action, which would inhibit any call > to remove_and_add_spares > - add the disk > - set recovery_start > - set the slot > - write 'recover' to sync_action > > It is unfortunate that the setting of 'slot' and 'recovery_start' > must be in different orders in the different cases, but maybe that > isn't a tragedy. > > Possibly I could change slot_store in the pers==NULL case to not > set In_sync if recovery_offset were not MaxSector, but > I'm not sure it is worth the effort. > > Does that answer your concerns? I had my mind set on a unified sysfs_add_disk() implementation that would fallback to recovery_start=0 in older kernels. But context sensitive 'add' routines frees me from this mental rat hole. Undoing the In_sync bit after the slot write is palatable given the alternatives. Thanks for the nudge. -- Dan -- 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
