Re: [GIT PATCH 0/2] external-metadata recovery checkpointing for 2.6.33
From: Dan Williams <hidden>
Date: 2009-12-16 06:24:41
On Tue, Dec 15, 2009 at 10:16 PM, Neil Brown [off-list ref] 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html