RAID1 question

Please keep me in the CC. I am not on the list.

If I have a RAID1 of 2 disks and I decide to move them to another computer
and recreate the raid, does it really need to do the initial recovery?

For that matter, when creating a RAID1 on 2 disks, is it really needed to do
the initial recovery?

I understand why it's needed for RAID4/5/6 though.
--
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

Re: RAID1 question

--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu Sep 29, 2011 at 02:34:57PM -0400, William Thompson wrote:

> Please keep me in the CC. I am not on the list.
>=20
> If I have a RAID1 of 2 disks and I decide to move them to another computer
> and recreate the raid, does it really need to do the initial recovery?
>=20
You don't need to recreate the raid at all, just reassemble it. You may
want to update the homehost though, otherwise it will (IIRC) auto
assemble to md_126 (or so) instead of md0.

> For that matter, when creating a RAID1 on 2 disks, is it really needed to=
do
> the initial recovery?
>=20
> I understand why it's needed for RAID4/5/6 though.
>
Probably not, no. Anything written would go to both mirrors, and reads
of any un-mirrored areas are indeterminate anyway. You would lose the
ability to check the array for mismatches though, and the recovery
process would bring everything into sync whenever it's run anyway. More
of a question would be why not do the initial recovery? It doesn't delay
access to the array, and at least the I/O load is happening at a
controlled point (rather than at recovery time, when you have no
control). Anyway, if you do want to avoid the initial recovery, just use
--assume-clean.

Cheers,
Robin
--=20
___ =20
( ' } | Robin Hill |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |

--XsQoSWH+UP9D9v3l
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iEYEARECAAYFAk6ExlIACgkQShxCyD40xBIwXgCfSXIXF901jDogHWm5poRG BQR+
PcUAniWH6HAtxH4oDCCZ1iCfEvg0+cE0
=ILwK
-----END PGP SIGNATURE-----

--XsQoSWH+UP9D9v3l--
--
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

Re: RAID1 question

On Thu, Sep 29, 2011 at 08:26:11PM +0100, Robin Hill wrote:
> On Thu Sep 29, 2011 at 02:34:57PM -0400, William Thompson wrote:
>
> > Please keep me in the CC. I am not on the list.
> >
> > If I have a RAID1 of 2 disks and I decide to move them to another computer
> > and recreate the raid, does it really need to do the initial recovery?
> >
> You don't need to recreate the raid at all, just reassemble it. You may
> want to update the homehost though, otherwise it will (IIRC) auto
> assemble to md_126 (or so) instead of md0.

The reason I asked this was because a mirrored pair that I currently have is
0.90 version and I was going to use 1.0

> > For that matter, when creating a RAID1 on 2 disks, is it really needed to do
> > the initial recovery?
> >
> > I understand why it's needed for RAID4/5/6 though.
> >
> Probably not, no. Anything written would go to both mirrors, and reads
> of any un-mirrored areas are indeterminate anyway. You would lose the

I figured this would be the case.

> ability to check the array for mismatches though, and the recovery
> process would bring everything into sync whenever it's run anyway. More

I've rarely done this. On large disks, this takes may hours to perform.

> of a question would be why not do the initial recovery? It doesn't delay
> access to the array, and at least the I/O load is happening at a
> controlled point (rather than at recovery time, when you have no

I guess the only reason I can come up with would be to avoid extra head
seeks. Well, that and the time it takes.

During the initial sync, if a write happens to an area that has been synced,
does it go to all drives? What about a write to an area that as not been
synced yet?

> control). Anyway, if you do want to avoid the initial recovery, just use
> --assume-clean.

I am aware of this option. I've have been fortunate with mdadm in the many
years I've used it (except 1 time).
--
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

Re: RAID1 question

--NMuMz9nt05w80d4+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu Sep 29, 2011 at 03:37:05PM -0400, William Thompson wrote:

> On Thu, Sep 29, 2011 at 08:26:11PM +0100, Robin Hill wrote:
> > On Thu Sep 29, 2011 at 02:34:57PM -0400, William Thompson wrote:
> >=20
> > > Please keep me in the CC. I am not on the list.
> > >=20
> > > If I have a RAID1 of 2 disks and I decide to move them to another com=
puter
> > > and recreate the raid, does it really need to do the initial recovery?
> > >=20
> > You don't need to recreate the raid at all, just reassemble it. You may
> > want to update the homehost though, otherwise it will (IIRC) auto
> > assemble to md_126 (or so) instead of md0.
>=20
> The reason I asked this was because a mirrored pair that I currently have=
is
> 0.90 version and I was going to use 1.0
>=20
You _should_ be able to do a --create --assume-clean there, without
losing the data, but I'd go with a backup, --create, and restore jsut to
be safe.

> > > For that matter, when creating a RAID1 on 2 disks, is it really needed
> > > to do the initial recovery?
> > >=20
> > > I understand why it's needed for RAID4/5/6 though.
> > >
> > Probably not, no. Anything written would go to both mirrors, and reads
> > of any un-mirrored areas are indeterminate anyway. You would lose the
>=20
> I figured this would be the case.
>=20
> > ability to check the array for mismatches though, and the recovery
> > process would bring everything into sync whenever it's run anyway. More
>=20
> I've rarely done this. On large disks, this takes may hours to perform.
>=20
It can, but it also ensures the disks are readable. If you don't run
regular checks, in a recovery situation you may hit a bad block on a
supposedly good disk and have a heap more trouble to deal with.

> > of a question would be why not do the initial recovery? It doesn't delay
> > access to the array, and at least the I/O load is happening at a
> > controlled point (rather than at recovery time, when you have no
>=20
> I guess the only reason I can come up with would be to avoid extra head
> seeks. Well, that and the time it takes.
>=20
> During the initial sync, if a write happens to an area that has been sync=
ed,
> does it go to all drives? What about a write to an area that as not been
> synced yet?
>=20
If the area has already been synced then writes will definitely go to
all members. I'm pretty sure this also happens in areas which haven't
been synced as well, but I'm not 100% on that.

Cheers,
Robin
--=20
___ =20
( ' } | Robin Hill |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |

--NMuMz9nt05w80d4+
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iEYEARECAAYFAk6E1CEACgkQShxCyD40xBIaSgCgqWdHsOIUEq4x6mrhLgpY 6BnW
6JoAoMzElUg9nQFAO2Q+PeGhdNwHbacr
=zVeT
-----END PGP SIGNATURE-----

--NMuMz9nt05w80d4+--
--
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

Re: RAID1 question

On 29. sep. 2011 21:37, William Thompson wrote:
> On Thu, Sep 29, 2011 at 08:26:11PM +0100, Robin Hill wrote:
>> On Thu Sep 29, 2011 at 02:34:57PM -0400, William Thompson wrote:
>>
>>> Please keep me in the CC. I am not on the list.
>>>
>>> If I have a RAID1 of 2 disks and I decide to move them to another computer
>>> and recreate the raid, does it really need to do the initial recovery?
>>>
>> You don't need to recreate the raid at all, just reassemble it. You may
>> want to update the homehost though, otherwise it will (IIRC) auto
>> assemble to md_126 (or so) instead of md0.
>
> The reason I asked this was because a mirrored pair that I currently have is
> 0.90 version and I was going to use 1.0

You'll find information about going from 0.90 to 1.0 in the archive,
take a look at these links:
http://thread.gmane.org/gmane.linux.raid/34014/focus=34029
http://thread.gmane.org/gmane.linux.raid/34424/focus=34441


--
Kai Stian Olstad
--
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

Re: RAID1 question

On Thu, Sep 29, 2011 at 09:25:05PM +0100, Robin Hill wrote:
> On Thu Sep 29, 2011 at 03:37:05PM -0400, William Thompson wrote:
>
> > On Thu, Sep 29, 2011 at 08:26:11PM +0100, Robin Hill wrote:
> > > You don't need to recreate the raid at all, just reassemble it. You may
> > > want to update the homehost though, otherwise it will (IIRC) auto
> > > assemble to md_126 (or so) instead of md0.
> >
> > The reason I asked this was because a mirrored pair that I currently have is
> > 0.90 version and I was going to use 1.0
> >
> You _should_ be able to do a --create --assume-clean there, without
> losing the data, but I'd go with a backup, --create, and restore jsut to
> be safe.

Agreed, however, in this case, I was going for a new raid with new data and
the disks would already be in sync.

> > > ability to check the array for mismatches though, and the recovery
> > > process would bring everything into sync whenever it's run anyway. More
> >
> > I've rarely done this. On large disks, this takes may hours to perform.
> >
> It can, but it also ensures the disks are readable. If you don't run
> regular checks, in a recovery situation you may hit a bad block on a
> supposedly good disk and have a heap more trouble to deal with.

Understood.

> > > of a question would be why not do the initial recovery? It doesn't delay
> > > access to the array, and at least the I/O load is happening at a
> > > controlled point (rather than at recovery time, when you have no
> >
> > I guess the only reason I can come up with would be to avoid extra head
> > seeks. Well, that and the time it takes.
> >
> > During the initial sync, if a write happens to an area that has been synced,
> > does it go to all drives? What about a write to an area that as not been
> > synced yet?
> >
> If the area has already been synced then writes will definitely go to
> all members. I'm pretty sure this also happens in areas which haven't
> been synced as well, but I'm not 100% on that.

Ok, thanks.
--
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

Re: RAID1 question

On Fri, Sep 30, 2011 at 08:15:27AM +0200, Kai Stian Olstad wrote:
> On 29. sep. 2011 21:37, William Thompson wrote:
> > The reason I asked this was because a mirrored pair that I currently have is
> > 0.90 version and I was going to use 1.0
>
> You'll find information about going from 0.90 to 1.0 in the archive,
> take a look at these links:
> http://thread.gmane.org/gmane.linux.raid/34014/focus=34029
> http://thread.gmane.org/gmane.linux.raid/34424/focus=34441

I'll look at those when I have time. In this specific case, I do not care
if the data is destroyed. Just wanted to know if the disks would still be
in sync.

For the sync part, I don't believe it would really matter which metadata
version I used, the disks would be in sync except for areas where the old
metadata was stored. Am I right on this? That is assuming RAID1.

--
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