Re: RAID1 Recovery

[malahal@us.ibm.com]

Trantow, Wayne D [wayne.d.trantow@intel.com] wrote:
> Hello,
> I am studying the dmraid-1.0.0.rc14, device-mapper_CVS Latest, and
> Fedora 6 (2.6.18-1.2798) kernel dmraid code to understand the recovery
> logic for a RAID1 set.  The usage scenario is where one disk in a mirror
> dies, the user swaps in a clean disk and then invokes dmraid app to
> copy/sync data to the new disk.
> 
> Within this context I have a couple questions:
> 
> - In kernel space, it looks like a recovery operation (RH_RECOVERING)
> will take place if the mirror_target.resume (mirror_resume) handler is
> called.  In user space, in dmraid/reconfig.c add_dev_to_set() func sets
> up handler add_dev_to_raid1() which should start the recovery.  However,
> as far as I can see, add_dev_to_set is not wired in to the rest of the
> dmraid code (i.e., nothing calls it).  What was the intent here?  
> 
> - If you follow the call chain from add_dev_to_raid1 into device-mapper
> it sets up a 'resume' call via an DM_DEV_RESUME ioctl dm_task, however,
> in the device-mapper _cmd_data_v4 struct (in libdm-iface.c) the 'resume'
> handler func is associated with the DM_DEV_SUSPEND ioctl not
> DM_DEV_RESUME. Hence, even if you invoked add_dev_to_raid1, a direct
> ioctl call to the kernel mirror_target.resume func is not possible.
> this a bug or intentional? Or am I not seeing it correctly?

Quick glance indicates that resume and suspend, they both, seem to use
suspend ioctl command.  DM_SUSPEND_FLAG is used to take the suspend
operation, otherwise resume operation is done. See dev_suspend() in
drivers/md/dm-ioctl.c