Re: Requesting replace mode for changing a disk

[SandeepKsinha <sandeepksinha@gmail.com>]

On Wed, May 13, 2009 at 10:51 AM, NeilBrown <neilb@suse.de> wrote:
> On Wed, May 13, 2009 3:07 pm, SandeepKsinha wrote:
>> On Wed, May 13, 2009 at 10:24 AM, Neil Brown <neilb@suse.de> wrote:
>>> On Wednesday May 13, sandeepksinha@gmail.com wrote:
>>>> Hi,
>>>>
>>>> On Wed, May 13, 2009 at 10:01 AM, Neil Brown <neilb@suse.de> wrote:
>>>> > On Tuesday May 12, lrhorer@satx.rr.com wrote:
>>>> >>
>>>> >> But doesn't creating the array with the drive wipe the contents?  If
>>>> so, it
>>>> >> doesn't seem to me this provides much redundancy.
>>>> >
>>>> > No.  Creating an array does not wipe the contents.
>>>> > It might cause a resync which will copy contents from one drive to
>>>> the
>>>> > other and I don't promise which one.
>>>> > However if you:
>>>> >
>>>> Now, my question is that what if I create a RAID1 with 100 disks on
>>>> each side.
>>>> Do you mean to say that there will be unnecessary resync happening
>>>> there as well, that too for unallocated/written data.
>>>
>>> I'm not sure what "100 disks on each side" means.
>>> Do you mean a raid1 across 100 devices?  i.e. 100 copies of each
>>> block?
>>>
>>
>> I meant we have two copies of 100 disks on each side of the mirror.
>> Sorry, I am not very sure how md would handle it but say, I created
>> two logical volumes of 100 disks and try to make a raid1 out of it.
>
> for example, two raid0 array, each out of 100 drives.  Then a raid1
> joining them.
> Yes, you could do that (though it would generally be better to create
> 100 raid1 pairs, and make a raid0 of them, but that is beside the point
> I think).
>
>>
>>> In any case, md has no concept of unallocated/written data.  Every
>>> block is potentially meaningful and needs to be copied for resync.
>>>
>>
>> So, while creation it is always guaranteed that a resync will always
>> happen. I believe this can be avoided by just adding some flags. The
>> user can specify its intention.
>
> You can get the resync not to happen by using the "--assume-clean"
> flag when you create the array.
> However that doesn't really save a lot and it will still have to do
> a complete copy if you ever fail a drive and replace it.
> So it is a small optimisation.
>
>
>>>>
>>>> If thats the case, we surely need to handle these two situations
>>>> differently (1) which neil mentioned (2) the one I mentioned above.
>>>>
>>>> Remember I referring to the case of creation.
>>>>
>>>> >   mdadm -C /dev/md0 --level 1 -n 2 /dev/foo missing
>>>> >   mdadm /dev/md0 --add /dev/bar
>>>> >
>>>> > then the contents on /dev/foo will not be changed (except for a few K
>>>> > at the end for the metadata) and then all of foo will be copied to
>>>> > bar.
>>>> >
>>>>
>>>> Will the create happen at the first place?
>>>
>>> I don't understand this question, sorry.
>>>
>> Actually I could not understand, what did you mean by "missing" in the
>> above line, which creates the array.
>
> Read the manpage for mdadm.
>
> The word "missing" means create the array without any device in this slot.
> It will be as though the device in that slot had failed and been removed.
>

Thanks but I am still confused. Here is what I see on the console.


[10:55:16 sinhas]$ sudo mdadm -C /dev/md0 --level 1 -n 2 /dev/sda5 missing
mdadm: /dev/sda5 appears to contain an ext2fs file system
    size=19535008K  mtime=Sun Apr  5 21:34:00 2009
mdadm: /dev/sda5 appears to be part of a raid array:
    level=raid1 devices=2 ctime=Wed May 13 10:06:33 2009
Continue creating array? y
mdadm: RUN_ARRAY failed: Invalid argument
mdadm: stopped /dev/md0

> NeilBrown
>
>



-- 
Regards,
Sandeep.





 	
“To learn is to change. Education is a process that changes the learner.”
--
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