Re: Requesting replace mode for changing a disk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 13, 2009 3:07 pm, SandeepKsinha wrote:
> On Wed, May 13, 2009 at 10:24 AM, Neil Brown <neilb@xxxxxxx> wrote:
>> On Wednesday May 13, sandeepksinha@xxxxxxxxx wrote:
>>> Hi,
>>>
>>> On Wed, May 13, 2009 at 10:01 AM, Neil Brown <neilb@xxxxxxx> wrote:
>>> > On Tuesday May 12, lrhorer@xxxxxxxxxxx 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.

NeilBrown

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux