debian software raid1

--=-8hu0FB9UWYi69RhahCia
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi , list=20
i have two identical 500GB harddrives - sda & sdb. sda has already
installed debian with root and other partitions and data on it and sdb
had no partiotions and data on it (it is brand new). my question is :
can i setup software raid 1 on two harddisks without loosing any data
from sda ? just to create raid array and somehow copy partitions and
data to it ?=20
sorry for my lame question , just don't know how (if possible) to do it.

--=-8hu0FB9UWYi69RhahCia
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJNrXw+AAoJEIN9/gu8BQLyE3cIAIkyDfwB7ewhRbDTXdb8 zAwk
qFZIz2PcBtPE7rt4CFEyJQU83fUJtT7k5fief9uRLXuc7C9UXJmlh3qMcwLX Gdvt
ivWOOLsElYkHhgTVTcAUKkwkFBbvbdN12gJEk1zO9CiEqbvKrhibvI4qgFk1 oTwV
8lOUku56QLsleIs7SwGM1jQcxh7epXpTbcGaozJcGhixIHNQxA3YryNvEOLx qlVZ
0ZtlEAVaECHkiiZqhuXMMbW+60ZY9UBAxaw7RJ3+Joicbz+MTDAK5QcVUlq/ u5AY
NIMqn3p4+OEF0/PsOLJ8nMkOlgyAgLuz+DfMtCfvF/ngbuiEMTH3d8fgnCSp Zzs=
=Re2y
-----END PGP SIGNATURE-----

--=-8hu0FB9UWYi69RhahCia--

--
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: debian software raid1

On 19 April 2011 13:12, b2 wrote:
> Hi , list
> i have two identical 500GB harddrives - sda & sdb. sda has already
> installed debian with root and other partitions and data on it and sdb
> had no partiotions and data on it (it is brand new). my question is :
> can i setup software raid 1 on two harddisks without loosing any data
> from sda ? just to create raid array and somehow copy partitions and
> data to it ?
> sorry for my lame question , just don't know how (if possible) to do it.
>

http://www.debian-administration.org/articles/238

Plenty of articles on the net on how to do that.

Regards,
M
--
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: debian software raid1

Hey guys,

On 04/19/11 08:25, Mathias Burén wrote:
> http://www.debian-administration.org/articles/238
>
> Plenty of articles on the net on how to do that.

There is a lot of information, but also, I suspect there is a lot of=20
disagreement. One thing that I could not find a definitive answer on wa=
s=20
the question of whether or not to mirror swap.

There are articles that propose mirroring partitions independently=20
(rather than the entire disk), and not mirroring swap, but adding two=20
swap partitions with equal priority. On the other hand, there are peopl=
e=20
who point out that in the event where one of the disks in the mirror=20
dies, the machine may cease to function, because a part of its "memory"=
=20
will have disappeared. However, making swap part of the mirror opens a=20
whole new can of worms. For instance, could there be a deadlock=20
possibility (for example after a suspend/resume cycle) where mdadm is=20
waiting for something which is swapped out onto swap which is mirrored?

It would be nice to have a discussion among people who have experience=20
with all of this.

Cheers,
Iordan
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: debian software raid1

On Tue, 19 Apr 2011, Iordan Iordanov wrote:

> There is a lot of information, but also, I suspect there is a lot of
> disagreement. One thing that I could not find a definitive answer on was the
> question of whether or not to mirror swap.
>
> There are articles that propose mirroring partitions independently (rather
> than the entire disk), and not mirroring swap, but adding two swap partitions
> with equal priority. On the other hand, there are people who point out that
> in the event where one of the disks in the mirror dies, the machine may cease
> to function, because a part of its "memory" will have disappeared. However,
> making swap part of the mirror opens a whole new can of worms. For instance,
> could there be a deadlock possibility (for example after a suspend/resume
> cycle) where mdadm is waiting for something which is swapped out onto swap
> which is mirrored?
>
> It would be nice to have a discussion among people who have experience with
> all of this.

I've not been active here for a long time - mostly because as far as I'm
concerned Linux-Raid "just works" and it's as stable as I need it to be,
however this subject caught my eye, so I'll add in my 2 penneth
worth...

I've been putting swap on mirrored, and raided drives for as long as I've
been using the MD stuff, and that's now well over 10 years now.

I do recall that there were such deadlock issues in the early days, but
I'm also sure these were resolved very quickly indeed. MD has certianly
saved my bacon when a disk has failled - and that includes swap
partitions.

An example - swap on a 5-drive RAID-6 system:

cat /proc/swaps
Filename Type Size Used Priority
/dev/md2 partition 2987704 1720 -1

and:

md2 : active raid6 sde2[4] sdd2[3] sdc2[2] sdb2[1] sda2[0]
2987712 blocks level 6, 64k chunk, algorithm 2 [5/5] [UUUUU]

another: (RAID1 - mirrored)

cat /proc/swaps
Filename Type Size Used Priority
/dev/md2 partition 2007992 0 -1

and:

md2 : active raid1 sdb2[0] sda2[1]
2008000 blocks [2/2] [UU]

however just because I do it, doesn't mean it's perfect - but I can say
that I've never had a server panic or otherwise crash due to me having
swap on MD - at least not that I've been aware of. (but also note that
I've never used MD on a system that I'd ever suspend or hibernate, but I
have used MD with drive spin-down software with no ill effects!)

I'm actually of the opinion that to NOT put swap on RAID in an otherwise
RAIDed system is just plain silly. Do it. You know it makes sense!

Gordon
--
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: debian software raid1

On 20/04/2011 7:10 AM, Gordon Henderson wrote:
> I'm actually of the opinion that to NOT put swap on RAID in an otherwise
> RAIDed system is just plain silly. Do it. You know it makes sense!

I think the preferred method at the moment (and at least for 2010/2011)
is to have a smallish RAID1 partition for /boot then create a second
RAID array for everything else and use LVM on top of that.

That allows you to have the host on the same RAID1 and use the
flexibility to use LVM for all your other requirements.

I personally run a Xen virtualisation server - it has the following:
/dev/md0 - /boot - 512Mb - RAID1
/dev/md1 - VG 'RAID1' - rest of disk - RAID1
/dev/md2 - VG 'RAID5' - 3 x 1Tb whole disks - RAID5

Then the majority of the 7 VMs on that machine live on the RAID5 VG
(with one special case that is on the RAID1 VG) and it runs very happily.

The swap and root of Dom0 is on the RAID1 VG. This seems to be the best
way I've found to have the most flexibility and not have to change
things as time progresses.

--
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

There are no great men, only great challenges that ordinary men are
forced by circumstances to meet. -- Admiral William Halsey
--
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: debian software raid1

hum, some doubts....
what=B4s better (faster / secure)?
swap over one disk (no raid)
swap over one md raid1
swap over one md raid0
swap over one md raid10
swap over one md raid5
swap over one md raid6



2011/4/19 Steven Haigh :
> On 20/04/2011 7:10 AM, Gordon Henderson wrote:
>>
>> I'm actually of the opinion that to NOT put swap on RAID in an other=
wise
>> RAIDed system is just plain silly. Do it. You know it makes sense!
>
> I think the preferred method at the moment (and at least for 2010/201=
1) is
> to have a smallish RAID1 partition for /boot then create a second RAI=
D array
> for everything else and use LVM on top of that.
>
> That allows you to have the host on the same RAID1 and use the flexib=
ility
> to use LVM for all your other requirements.
>
> I personally run a Xen virtualisation server - it has the following:
> /dev/md0 - /boot - 512Mb - RAID1
> /dev/md1 - VG 'RAID1' - rest of disk - RAID1
> /dev/md2 - VG 'RAID5' - 3 x 1Tb whole disks - RAID5
>
> Then the majority of the 7 VMs on that machine live on the RAID5 VG (=
with
> one special case that is on the RAID1 VG) and it runs very happily.
>
> The swap and root of Dom0 is on the RAID1 VG. This seems to be the be=
st way
> I've found to have the most flexibility and not have to change things=
as
> time progresses.
>
> --
> Steven Haigh
>
> Email: netwiz@crc.id.au
> Web: http://www.crc.id.au
> Phone: (03) 9001 6090 - 0412 935 897
> Fax: (03) 8338 0299
>
> There are no great men, only great challenges that ordinary men are f=
orced
> by circumstances to meet. -- Admiral William Halsey
> --
> 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 =A0http://vger.kernel.org/majordomo-info.html
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: debian software raid1

On 19 April 2011 23:01, Roberto Spadim wrote:
> hum, some doubts....
> what´s better (faster / secure)?
> swap over one disk (no raid)
> swap over one md raid1
> swap over one md raid0
> swap over one md raid10
> swap over one md raid5
> swap over one md raid6
>
>
>
> 2011/4/19 Steven Haigh :
>> On 20/04/2011 7:10 AM, Gordon Henderson wrote:
>>>
>>> I'm actually of the opinion that to NOT put swap on RAID in an othe=
rwise
>>> RAIDed system is just plain silly. Do it. You know it makes sense!
>>
>> I think the preferred method at the moment (and at least for 2010/20=
11) is
>> to have a smallish RAID1 partition for /boot then create a second RA=
ID array
>> for everything else and use LVM on top of that.
>>
>> That allows you to have the host on the same RAID1 and use the flexi=
bility
>> to use LVM for all your other requirements.
>>
>> I personally run a Xen virtualisation server - it has the following:
>> /dev/md0 - /boot - 512Mb - RAID1
>> /dev/md1 - VG 'RAID1' - rest of disk - RAID1
>> /dev/md2 - VG 'RAID5' - 3 x 1Tb whole disks - RAID5
>>
>> Then the majority of the 7 VMs on that machine live on the RAID5 VG =
(with
>> one special case that is on the RAID1 VG) and it runs very happily.
>>
>> The swap and root of Dom0 is on the RAID1 VG. This seems to be the b=
est way
>> I've found to have the most flexibility and not have to change thing=
s as
>> time progresses.
>>
>> --
>> Steven Haigh
>>
>> Email: netwiz@crc.id.au
>> Web: http://www.crc.id.au
>> Phone: (03) 9001 6090 - 0412 935 897
>> Fax: (03) 8338 0299
>>
>> There are no great men, only great challenges that ordinary men are =
forced
>> by circumstances to meet. -- Admiral William Halsey
>> --
>> 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.h=
tml
>>
>
>
>
> --
> Roberto Spadim
> Spadim Technology / SPAEmpresarial
> --
> 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.ht=
ml
>

You can't say "faster/secure", it's mostly either one. Swap over raid0
or some raid10 implementation would probably be the fastest. Swap on
raid456 would be incredibly slow write wise...
// M
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: debian software raid1

On Tue, 19 Apr 2011 12:03:27 -0400 Iordan Iordanov edu>
wrote:

> Hey guys,
>=20
> On 04/19/11 08:25, Mathias Bur=E9n wrote:
> > http://www.debian-administration.org/articles/238
> >
> > Plenty of articles on the net on how to do that.
>=20
> There is a lot of information, but also, I suspect there is a lot of=20
> disagreement. One thing that I could not find a definitive answer on =
was=20
> the question of whether or not to mirror swap.
>=20
> There are articles that propose mirroring partitions independently=20
> (rather than the entire disk), and not mirroring swap, but adding two=
=20
> swap partitions with equal priority. On the other hand, there are peo=
ple=20
> who point out that in the event where one of the disks in the mirror=20
> dies, the machine may cease to function, because a part of its "memor=
y"=20
> will have disappeared. However, making swap part of the mirror opens =
a=20
> whole new can of worms. For instance, could there be a deadlock=20
> possibility (for example after a suspend/resume cycle) where mdadm is=
=20
> waiting for something which is swapped out onto swap which is mirrore=
d?

If there was such a deadlock, it would be a serious bug. I don't beli=
eve
such a bug exists (but hey - I keep finding bugs in this code, when I'm=
not
busy writing new bugs, so I guess it could crash you machine and kill y=
our
cat).

>=20
> It would be nice to have a discussion among people who have experienc=
e=20
> with all of this.

Definitely put swap on RAID1 if you have RAID1 at all.

My personal preference with RAID1 to to have a single RAID1 (probably
--metadata=3D1.0) across the whole devices, and partition that for root=
, swap,
home.

Others prefer to partition the devices and run RAID1 across the partiti=
ons
independently. While that is not my preference I known nothing against=
it.
This is the price of freedom - you have to make choices

If I had a few identical drives, I would partition them each into a
small /boot, a small swap and the rest. I would then RAID1 all the /bo=
ots
together, RAID10 all the swaps, and RAID5 or RAID6 all the rest.

The most important thing though it to create an configuration that you
understand and are comfortable with, because you are the one who will h=
ave to
manage it.

NeilBrown


>=20
> Cheers,
> Iordan
> --
> 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

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

Re: debian software raid1

On 04/19/2011 06:51 PM, NeilBrown wrote:
> On Tue, 19 Apr 2011 12:03:27 -0400 Iordan Iordanov

[...]

> If there was such a deadlock, it would be a serious bug. I don't believe
> such a bug exists (but hey - I keep finding bugs in this code, when I'm not
> busy writing new bugs, so I guess it could crash you machine and kill your
> cat).

I ran into this a few years ago (early 2.6 series, maybe 2.6.15 or so).
Some sort of race condition. Required a reset to get the machines
attention. Haven't tried since. Since we do lots of MD raid, I
generally either put the swap on hardware RAID, or stripe it and
sometimes hope for the best. The latter doesn't always work. When a
drive goes pear shaped, and takes down pages with it, your machine will
crash, and pretty hard at that.

We'll definitely try the swap atop MD RAID going forward. I like the
idea of a RAID10 for it.

>> It would be nice to have a discussion among people who have experience
>> with all of this.
>
> Definitely put swap on RAID1 if you have RAID1 at all.
>
> My personal preference with RAID1 to to have a single RAID1 (probably
> --metadata=1.0) across the whole devices, and partition that for root, swap,
> home.

This gets to my question, since we haven't tried this yet ... can we do
whole device MD RAIDs, and boot from them? Is there anything special we
need to do in their construction (use --auto=mdp or similar)? We'd
really prefer to go this route rather than building multiple smaller
RAIDs. We can manage the latter, but the former is far easier/cleaner
to handle rebuilds with.

Regards,

Joe


--
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics, Inc.
email: landman@scalableinformatics.com
web : http://scalableinformatics.com
http://scalableinformatics.com/sicluster
phone: +1 734 786 8423 x121
fax : +1 866 888 3112
cell : +1 734 612 4615
--
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: debian software raid1

On Tue, 19 Apr 2011 20:33:46 -0400 Joe Landman wrote:

> On 04/19/2011 06:51 PM, NeilBrown wrote:
> > On Tue, 19 Apr 2011 12:03:27 -0400 Iordan Iordanov
>
> [...]
>
> > If there was such a deadlock, it would be a serious bug. I don't believe
> > such a bug exists (but hey - I keep finding bugs in this code, when I'm not
> > busy writing new bugs, so I guess it could crash you machine and kill your
> > cat).
>
> I ran into this a few years ago (early 2.6 series, maybe 2.6.15 or so).
> Some sort of race condition. Required a reset to get the machines
> attention.

I wonder what this might have been...
Resume from suspend when swap in on md/raid can be a bit tricky and may not
have been well tested at that time. You need to be able to assemble the
RAID1 for read without writing anything. That can be done now by setting the
'start_ro' module parameter (echo 1
> /sys/modules/md_mod/parameters/start_ro).

I haven't actually tested it myself though so I cannot speak from experience.

> Haven't tried since. Since we do lots of MD raid, I
> generally either put the swap on hardware RAID, or stripe it and
> sometimes hope for the best. The latter doesn't always work. When a
> drive goes pear shaped, and takes down pages with it, your machine will
> crash, and pretty hard at that.
>
> We'll definitely try the swap atop MD RAID going forward. I like the
> idea of a RAID10 for it.
>
> >> It would be nice to have a discussion among people who have experience
> >> with all of this.
> >
> > Definitely put swap on RAID1 if you have RAID1 at all.
> >
> > My personal preference with RAID1 to to have a single RAID1 (probably
> > --metadata=1.0) across the whole devices, and partition that for root, swap,
> > home.
>
> This gets to my question, since we haven't tried this yet ... can we do
> whole device MD RAIDs, and boot from them? Is there anything special we
> need to do in their construction (use --auto=mdp or similar)? We'd
> really prefer to go this route rather than building multiple smaller
> RAIDs. We can manage the latter, but the former is far easier/cleaner
> to handle rebuilds with.

The little 'server' in my garage runs md/raid1 across two device (using 0.90
metadata - never had any reason to convert).

I seem to remember that I had to do something special to grub to get it to
boot initially, but I also vaguely remember that after some series of updates
(this is Debian) it seemed to get a lot easier. My "grub.cfg" contains:

menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-686' --class debian --class gnu-linux --class gnu --class os {
insmod raid
insmod mdraid
insmod part_msdos
insmod ext2
set root='(md0,1)'
search --no-floppy --fs-uuid --set 03e9951f-d174-4d88-9b4c-dd7a31c0de61
echo 'Loading Linux 2.6.32-5-686 ...'
linux /vmlinuz-2.6.32-5-686 root=UUID=6e8a3564-5588-476e-bbe5-a68c967c6c8e ro quiet
echo 'Loading initial ramdisk ...'
initrd /initrd.img-2.6.32-5-686
}

which was all automatically created, and it seems to "just work".

So yes - you can boot for partitioned whole-device md/raid.
You might need to use a "metadata-at-the-end" format list 0.90 or 1.0, but it
is entirely possible that it will work for other metadata formats, I really
don't know. Other than that, no special options needed when creating the
array.

NeilBrown
--
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: debian software raid1

On 04/20/11 00:51, NeilBrown wrote:
> If there was such a deadlock, it would be a serious bug. I don't believe
> such a bug exists (but hey - I keep finding bugs in this code, when I'm not
> busy writing new bugs, so I guess it could crash you machine and kill your
> cat).
>

I am aware that raids 0,1,10 do not copy the buffer so I don't think
there is risk of deadlock...

Raids 456 do copy the buffer... but the destination buffers are
preallocated, right?

Thank you
--
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: debian software raid1

On Wed, 20 Apr 2011 12:28:45 +0200 Asdo wrote:

> On 04/20/11 00:51, NeilBrown wrote:
> > If there was such a deadlock, it would be a serious bug. I don't believe
> > such a bug exists (but hey - I keep finding bugs in this code, when I'm not
> > busy writing new bugs, so I guess it could crash you machine and kill your
> > cat).
> >
>
> I am aware that raids 0,1,10 do not copy the buffer so I don't think
> there is risk of deadlock...
>
> Raids 456 do copy the buffer... but the destination buffers are
> preallocated, right?

Correct - destination buffers - when used - are preallocated.

If this were not the case you would get deadlocks in normal usage without
having to wait for suspend/resume to trigger them.

NeilBrown
--
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: debian software raid1

Hi Joe,

On 04/19/11 20:33, Joe Landman wrote:
> This gets to my question, since we haven't tried this yet ... can we do
> whole device MD RAIDs, and boot from them? Is there anything special we
> need to do in their construction (use --auto=mdp or similar)? We'd
> really prefer to go this route rather than building multiple smaller
> RAIDs. We can manage the latter, but the former is far easier/cleaner to
> handle rebuilds with.

A few days ago (just before this thread started, coincidentally), I
converted a single drive system to RAID1 by adding a second disk, and
raiding the whole drive. This does have the drawback that any
replacement drives have to be the same size or bigger than what you had
to begin with. I am running Ubuntu 10.04.

A few things I had to make sure, and I disclaim that this is not an
exhaustive list. I created the array and named it /dev/md0. Then, I had
to do:

1) mdadm --examine --scan > /etc/mdadm/mdadm.conf
2) Rebuild initrd, so that upon boot the array will be assembled
automatically based on this mdadm.conf. On Debian/Ubuntu, this can be
done with update-initramfs.

When you partition /dev/md0 with whatever partitioner you prefer, the
kernel does see the partitions, and makes /dev/md0pN for partition
number N. Hence you can use these to mount/start swap.

For the record, I have been suspending/resuming that Ubuntu 10.04 with
swap living on one of the RAID1 partitions with no ill effect, and will
revisit this thread if I ever do experience issues!

Also, I was thinking of switching from RAID1 to RAID10 with near layout
and two copies (effectively RAID1) in order to get faster reads -
anybody have any opinion on this?

Cheers everyone, and thanks for all the discussion!
Iordan
--
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: debian software raid1

Hi Neil,

On 04/19/11 21:12, NeilBrown wrote:
> I seem to remember that I had to do something special to grub to get it to
> boot initially, but I also vaguely remember that after some series of updates
> (this is Debian) it seemed to get a lot easier. My "grub.cfg" contains:
>
> menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-686' --class debian --class gnu-linux --class gnu --class os {
> insmod raid
> insmod mdraid
> insmod part_msdos
> insmod ext2
> set root='(md0,1)'
> search --no-floppy --fs-uuid --set 03e9951f-d174-4d88-9b4c-dd7a31c0de61
> echo 'Loading Linux 2.6.32-5-686 ...'
> linux /vmlinuz-2.6.32-5-686 root=UUID=6e8a3564-5588-476e-bbe5-a68c967c6c8e ro quiet
> echo 'Loading initial ramdisk ...'
> initrd /initrd.img-2.6.32-5-686
> }
>
> which was all automatically created, and it seems to "just work".

Yes, I am also reminded now that grub and md was a bit strange, mostly
because I was converting a single drive system to a RAID1 system, and I
had dd-d /dev/sda onto /dev/sdb. Grub seemed to struggle with the fact
that the UUID was the same on /dev/sda1, /dev/sdb1, and naturally
/dev/md0p1, which was initially created on top of /dev/sda. It refused
to boot a couple of times complaining about the UUID, which was easily
resolved by editing the grub entry on the fly in the grub prompt, and
changing root=UUID=6e8a3564-5588-476e-bbe5-a68c967c6c8e to
root=/dev/md0p1 (note that the UUID is just an example UUID), and
booting that way. Afterward, doing:

grub-install --modules="raid" /dev/md0

seemed to eventually placate grub. Also, I did not really see any change
in grub.cfg, but then again, I didn't actually do a "diff" of grub.cfg
before and after. The point is that it still uses UUID, the UUID is
still the same among all these devices (naturally, since this is RAID1),
and it *no longer complains*. It's a bit disconcerting, but I will learn
to live with it :D.

I hope this helps!
Iordan
--
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: debian software raid1

On Wed, Apr 20, 2011 at 10:51:29AM -0400, Iordan Iordanov wrote:
> raiding the whole drive. This does have the drawback that any replacement
> drives have to be the same size or bigger than what you had to begin with.

I am missing your point here.
The requirement of having a replacement drive at least as big as the
original one, usually comes from the fact that a smaller drive won't be
able to contain your data, not from some md voodoo.

If someone here still believes that drives from different vendors with
the same nominal size have different real size please read:
http://www.idema.org/wp-content/plugins/download-monitor/dow nload.php?id=1192


--
Luca Berra -- bluca@comedia.it
--
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: debian software raid1

Hi Luca,

On 04/21/11 02:15, Luca Berra wrote:
> If someone here still believes that drives from different vendors with
> the same nominal size have different real size please read:
> http://www.idema.org/wp-content/plugins/download-monitor/dow nload.php?id=1192

I don't think my point is invalid. If you wanted to mix SSDs and spindle
HDDs (for, say, write-mostly "backup" of the SSDs), quite likely your
drives will be of different sizes, as the SSDs frequently come in sizes
that are power of two's unlike the spindle drives. You could start of
with just one type of drive, and only then come up with the idea of
mixing types, etc. Probably not the best example, but one nonetheless.

There are other benefits to using a partition instead of the whole
device. For example, you could use a GPT label, which allows you to
label individual partitions. In an earlier post, I sent out a gpt_id
script and UDEV rules which insert /dev/disk/by-label/ links for you to
GPT-labeled partitions. We use it at the CS department of U of Toronto
to keep track of the physical location of disks (within iscsi target hosts).

I think that if you are not interested in the 2nd point here, you could
simply use the --size option to mdadm to use less than the total
capacity of the drives, but apparently it doesn't work for all RAID
levels (RAID 10 is not listed in Debian Lenny's man-page). Somebody
correct me if I am wrong about this.

Cheers!
Iordan

--
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: debian software raid1

On Thu, Apr 21, 2011 at 10:50:28AM -0400, Iordan Iordanov wrote:
> Hi Luca,
>
> On 04/21/11 02:15, Luca Berra wrote:
>> If someone here still believes that drives from different vendors with
>> the same nominal size have different real size please read:
>> http://www.idema.org/wp-content/plugins/download-monitor/dow nload.php?id=1192
>
> I don't think my point is invalid. If you wanted to mix SSDs and spindle
> HDDs (for, say, write-mostly "backup" of the SSDs), quite likely your
> drives will be of different sizes, as the SSDs frequently come in sizes
> that are power of two's unlike the spindle drives. You could start of with
> just one type of drive, and only then come up with the idea of mixing
> types, etc. Probably not the best example, but one nonetheless.
no, not the best example :D

> There are other benefits to using a partition instead of the whole device.
there are both benefits and disadvantages, both lists are long enough
without adding non-issues.

> For example, you could use a GPT label, which allows you to label
> individual partitions. In an earlier post, I sent out a gpt_id script and
> UDEV rules which insert /dev/disk/by-label/ links for you to GPT-labeled
> partitions. We use it at the CS department of U of Toronto to keep track of
> the physical location of disks (within iscsi target hosts).
So, if i understood correctly, you use partitions on something which is
not a real HDD, hope you got the data alignment part correct.

L.
--
Luca Berra -- bluca@comedia.it
--
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: debian software raid1

On 04/22/11 01:59, Luca Berra wrote:
> no, not the best example :D

I don't know why I'm even bothering to reply, given your all-knowing
tone, but here it is anyway. Today, I was converting a system from
single drive to mirrored with a 2nd 80GB drive. Here is proof that there
are drives that both claim to be 80GB, but happen to be of different
capacities:

sd 0:0:0:0: [sda] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
sd 2:0:0:0: [sdb] 156250000 512-byte logical blocks: (80.0 GB/74.5 GiB)

> So, if i understood correctly, you use partitions on something which
> isnot a real HDD, hope you got the data alignment part correct.

You have misunderstood, and yes we are using partitions on real drives,
and indeed yes, we've got the alignment part correct.

Cheers,
Iordan
--
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: debian software raid1

Hello again,

On 04/19/11 08:12, b2 wrote:
> sorry for my lame question , just don't know how (if possible) to do it.

After the 3rd system I had to do this on in the last 3 days, I decided
to write a guide myself :). I hope it helps!

http://iiordanov.blogspot.com/2011/04/how-to-convert-your-si ngle-drive-linux.html

Cheers,
Iordan
--
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: debian software raid1

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

---137064504-475235756-1303500508=:13186
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Fri, 22 Apr 2011, Iordan Iordanov wrote:

> I don't know why I'm even bothering to reply, given your all-knowing
> tone, but here it is anyway. Today, I was converting a system from
> single drive to mirrored with a 2nd 80GB drive. Here is proof that there
> are drives that both claim to be 80GB, but happen to be of different
> capacities:

"At that time, 3.5” 160GB have been shipping for a while so many
system manufacturers have already defined their own LBA counts
requirement. Most system
manufacturers began to adopt the LBA1-02 implementation at or after 3.5”
320GB density point."

The document never claims to be about 80GB drives.

--
Mikael Abrahamsson email: swmike@swm.pp.se
---137064504-475235756-1303500508=:13186--
--
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: debian software raid1

On Fri, 22 Apr 2011 15:21:39 -0400 Iordan Iordanov
wrote:

> Hello again,
>
> On 04/19/11 08:12, b2 wrote:
> > sorry for my lame question , just don't know how (if possible) to do it.
>
> After the 3rd system I had to do this on in the last 3 days, I decided
> to write a guide myself :). I hope it helps!
>
> http://iiordanov.blogspot.com/2011/04/how-to-convert-your-si ngle-drive-linux.html



> Create the array. I decided to make a RAID10 array instead of a RAID1 array,
> which gives me faster sequential reads, but amounts to the same thing in terms
> of data replication. RAID10 with two drives and "n2"

This is not correct. RAID10-n2 on 2 drives is exactly the same layout and
very nearly the same speed as RAID1 on 2 drives. (I say 'very nearly' only
because the read-balancing code is a little different and might have slightly
different results).

Or have you measured these two and found an actually difference? That would
certainly be interesting.

RAID10-f2 will give faster sequential reads at the cost of slower writes.

NeilBrown



>
> Cheers,
> Iordan
> --
> 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

--
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: debian software raid1

Hi Neil,

On 04/22/11 18:12, NeilBrown wrote:
> This is not correct. RAID10-n2 on 2 drives is exactly the same layout and
> very nearly the same speed as RAID1 on 2 drives. (I say 'very nearly' only
> because the read-balancing code is a little different and might have slightly
> different results).
>
> Or have you measured these two and found an actually difference? That would
> certainly be interesting.

The difference that I see is probably 100% due to the different read
balancing algorithm. When I start two dd processes reading from two
separate partitions on the RAID (just so there are no buffers screwing
up my results), with RAID1, I see less than one drive worth of
sequential read speed for the two dd processes combined.

On the other hand, with RAID10 I see the two drives being utilized
fully, and I get one drive worth of sequential read speeds for each dd
process, or a total of two drives worth of read speed for the two dd
processes.

The numbers were something like this:

- Single drive speed: ~130MB/s sequential read.
- Two simultaneous dd sequential reads with RAID1, bs=1024k: ~40MB/s per dd.
- Two simultaneous dd sequential reads with RAID10, bs=1024k: ~130MB/s
per dd.

That's what I meant by better sequential reads, but perhaps I should try
to phrase it more precisely.

> RAID10-f2 will give faster sequential reads at the cost of slower writes.

I am not sure what RAID10-f2 on a two disk setup will look like, but I
like the idea of the drives being identical, and in the worst case,
being able to pull one drive, zero the superblock, and be left with a
drive with intact data, which only RAID10-n2 can give, if I am not mistaken.

Just to follow up on our discussion on Grub v2 and booting from a RAID
device. I discovered that if I allow Grub to use UUID, occasionally, it
would try to mount a raw device for root instead of the RAID device.
Apart from the nuisance, this would probably cause mismatch_cnt to be
non-zero!! (heh heh). At any rate, the guide reflects how I deal with
that - by turning off the use of UUIDs.

Many thanks for taking a look at the guide and sharing your thoughts!
Please let me know if you still think I should change that part where I
say that RAID10 gives me faster sequential reads, and what you would say
instead.

Iordan
--
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: debian software raid1

Hi Mikael,

On 04/22/11 15:28, Mikael Abrahamsson wrote:
> The document never claims to be about 80GB drives.

But the document was proffered as proof that drives from different
manufacturers have the same capacity, whereas I find this to not be the
case for smaller drives. I never claimed the document is for 80GB drives.

Cheers,
Iordan
--
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: debian software raid1

On 19/04/11 18:03, Iordan Iordanov wrote:
> There are articles that propose mirroring partitions independently
> (rather than the entire disk), and not mirroring swap, but adding two
> swap partitions with equal priority.

Adding two swap partitions with equal priority is swap's way of
implementing striping rather than mirroring.

So it depends what you're after: if you want as much swap space as
possible then don't use md for swap and just create several swap
partitions with equal priority. If on the other hand you're after
robustness, in particular including the ability for the server to
survive disk failure, then you will need to add a RAID layer.

You can of course do both. In a previous machine I had a 4-disk RAID5.
On each of the 4 disks I had also set aside some space, which I
organised into two 2-partition RAID0 devices, which I then used as swap
devices with equal priority.

I have not experienced any deadlock issues with this setup.

Jan
--
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: debian software raid1

On 23/04/11 02:05, Iordan Iordanov wrote:
> Hi Neil,
>
> On 04/22/11 18:12, NeilBrown wrote:
>> This is not correct. RAID10-n2 on 2 drives is exactly the same layout and
>> very nearly the same speed as RAID1 on 2 drives. (I say 'very nearly'
>> only
>> because the read-balancing code is a little different and might have
>> slightly
>> different results).
>>
>> Or have you measured these two and found an actually difference? That
>> would
>> certainly be interesting.
>
> The difference that I see is probably 100% due to the different read
> balancing algorithm. When I start two dd processes reading from two
> separate partitions on the RAID (just so there are no buffers screwing
> up my results), with RAID1, I see less than one drive worth of
> sequential read speed for the two dd processes combined.
>
> On the other hand, with RAID10 I see the two drives being utilized
> fully, and I get one drive worth of sequential read speeds for each dd
> process, or a total of two drives worth of read speed for the two dd
> processes.
>
> The numbers were something like this:
>
> - Single drive speed: ~130MB/s sequential read.
> - Two simultaneous dd sequential reads with RAID1, bs=1024k: ~40MB/s per
> dd.
> - Two simultaneous dd sequential reads with RAID10, bs=1024k: ~130MB/s
> per dd.
>
> That's what I meant by better sequential reads, but perhaps I should try
> to phrase it more precisely.
>
>> RAID10-f2 will give faster sequential reads at the cost of slower writes.
>
> I am not sure what RAID10-f2 on a two disk setup will look like, but I
> like the idea of the drives being identical, and in the worst case,
> being able to pull one drive, zero the superblock, and be left with a
> drive with intact data, which only RAID10-n2 can give, if I am not
> mistaken.
>

Look at this to see some pictures of raid10 layouts:


Raid10,far will fair worse than raid10,near when degraded. But it will
still work - your data is mirrored, and you can pull a drive without
losing anything.

> Just to follow up on our discussion on Grub v2 and booting from a RAID
> device. I discovered that if I allow Grub to use UUID, occasionally, it
> would try to mount a raw device for root instead of the RAID device.
> Apart from the nuisance, this would probably cause mismatch_cnt to be
> non-zero!! (heh heh). At any rate, the guide reflects how I deal with
> that - by turning off the use of UUIDs.
>
> Many thanks for taking a look at the guide and sharing your thoughts!
> Please let me know if you still think I should change that part where I
> say that RAID10 gives me faster sequential reads, and what you would say
> instead.
>
> Iordan
> --
> 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
>


--
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: debian software raid1

On Fri, Apr 22, 2011 at 08:05:06PM -0400, Iordan Iordanov wrote:
> Hi Neil,
>
> On 04/22/11 18:12, NeilBrown wrote:
> >This is not correct. RAID10-n2 on 2 drives is exactly the same layout and
> >very nearly the same speed as RAID1 on 2 drives. (I say 'very nearly' only
> >because the read-balancing code is a little different and might have
> >slightly
> >different results).

Well, I think it has some significantly different results with the
different load balancing algorithms. For example the one reported in
this thread. Also other bemchmarks indicate this.

> >Or have you measured these two and found an actually difference? That
> >would
> >certainly be interesting.
>
> The difference that I see is probably 100% due to the different read
> balancing algorithm. When I start two dd processes reading from two
> separate partitions on the RAID (just so there are no buffers screwing
> up my results), with RAID1, I see less than one drive worth of
> sequential read speed for the two dd processes combined.
>
> On the other hand, with RAID10 I see the two drives being utilized
> fully, and I get one drive worth of sequential read speeds for each dd
> process, or a total of two drives worth of read speed for the two dd
> processes.
>
> The numbers were something like this:
>
> - Single drive speed: ~130MB/s sequential read.
> - Two simultaneous dd sequential reads with RAID1, bs=1024k: ~40MB/s per dd.
> - Two simultaneous dd sequential reads with RAID10, bs=1024k: ~130MB/s
> per dd.
>
> That's what I meant by better sequential reads, but perhaps I should try
> to phrase it more precisely.
>
> >RAID10-f2 will give faster sequential reads at the cost of slower writes.

The writes will not be much slower, maybe 3 % slower, and in some cases
faster, according to some benchmarks.

> I am not sure what RAID10-f2 on a two disk setup will look like, but I
> like the idea of the drives being identical, and in the worst case,
> being able to pull one drive, zero the superblock, and be left with a
> drive with intact data, which only RAID10-n2 can give, if I am not mistaken.

Yes, RAID10-far and RAID10-offset will not do that. However both
RAID10-far and RAID10-offset will be able to run in degraded mode with
just one disk, and with all data intact.

raid10-far will perform similarily to raid10-near with 2 dd'sC, also a
near 100 % utilization of both drives. however, with just 1 dd,
raid10-far wil also give almost 100 % utilization on bothe drives, while
raid10-near will give 100 % on one drive and 0 % on the other drive (I
think). Also when you ar doing multiple IO, RAID10-far will tend to give
you speeds for an additional sequential read above the speed of a single
drive - none of the other MD raid1/10 formats would do that.


> Just to follow up on our discussion on Grub v2 and booting from a RAID
> device. I discovered that if I allow Grub to use UUID, occasionally, it
> would try to mount a raw device for root instead of the RAID device.
> Apart from the nuisance, this would probably cause mismatch_cnt to be
> non-zero!! (heh heh). At any rate, the guide reflects how I deal with
> that - by turning off the use of UUIDs.
>
> Many thanks for taking a look at the guide and sharing your thoughts!
> Please let me know if you still think I should change that part where I
> say that RAID10 gives me faster sequential reads, and what you would say
> instead.

best regards
keld
--
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