Thread (11 messages) 11 messages, 2 authors, 2009-12-16

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help