Re: [GIT PATCH 0/2] external-metadata recovery checkpointing for 2.6.33

[Dan Williams <dan.j.williams@intel.com>]

On Tue, Dec 15, 2009 at 10:16 PM, Neil Brown <neilb@suse.de> 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