From: Michel Bouissou <michel@bouissou.net>
To: evms-devel@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com, neilb@cse.unsw.edu.au
Subject: Re: MD sequential / parallel resync issue with DM devices
Date: Mon, 18 Jul 2005 10:53:37 +0200 [thread overview]
Message-ID: <200507181053.37538@totor.bouissou.net> (raw)
In-Reply-To: <200507181037.01855@totor.bouissou.net>
Le Lundi 18 Juillet 2005 10:37, I wrote (on the evms-devel ML) :
>
> In kernel 2.4, MD thinks that all DM devices are "on the same physical
> disk" (and issues a dummy warning about this), and it resyncs them
> sequentially, which may or may not be optimal, but at least doesn't cause
> any problem.
>
> In kernel 2.6, MD does not issue any such warning, so it probably thinks
> that none of the DM devices are on the same physical disks (even though
> they may be), that's probably why it resyncs all of them in parallel.
>
> Actually, performing parallel resync is a good idea when RAID sets members
> reside on separate disks, but of course it is a very bad idea when they are
> on the same disks.
> The MD driver is confused about this by the DM layer, hence the problem.
And this is probably because the MD driver doesn't seem to see DM devices with
the same names in 2.4 or in 2.6.
On my system, a typical "cat /proc/mdstat" with kernel 2.4 showed:
Personalities : [raid1] [raid5]
read_ahead 1024 sectors
md2 : active raid1 [dev fe:2e][2] [dev fe:2d][1] [dev fe:2c][0]
1048704 blocks [2/2] [UU]
md3 : active raid5 [dev fe:1c][2] [dev fe:1b][1] [dev fe:1a][0]
151556992 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
md0 : active raid1 [dev fe:18][2] [dev fe:17][1] [dev fe:16][0]
261952 blocks [2/2] [UU]
md1 : active raid1 [dev fe:02][2] [dev fe:01][1] [dev fe:00][0]
1048704 blocks [2/2] [UU]
unused devices: <none>
Where on the same system, in 2.6, it shows :
Personalities : [raid1] [raid5]
md3 : active raid5 dm-28[2] dm-27[1] dm-26[0]
151556992 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
md2 : active raid1 dm-46[2] dm-45[1] dm-44[0]
1048704 blocks [2/2] [UU]
md1 : active raid1 dm-2[2] dm-1[1] dm-0[0]
1048704 blocks [2/2] [UU]
md0 : active raid1 dm-24[2] dm-23[1] dm-22[0]
261952 blocks [2/2] [UU]
unused devices: <none>
As you can see, in kernel 2.4, MD sees DM devices all called "fe:<number>",
and it may interpret all these "fe:<number>" as being the same physical
device (fe).
In 2.6, MD sees DM devices as called "dm-<number>", and it may interpret all
these "dm-<number>" as being all different physical devices.
It may have something to do with the way the MD driver parses/understands the
devices names/numbers, the ":" or "-", etc.
But this is just a supposition, some kernel-knowledgeable folk should probably
take a look at the DM code to understand this better.
(I'll be on travel for the week and may or may not have access to my email ;-)
Cheers.
--
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E
parent reply other threads:[~2005-07-18 8:53 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <200507181037.01855@totor.bouissou.net>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200507181053.37538@totor.bouissou.net \
--to=michel@bouissou.net \
--cc=evms-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=neilb@cse.unsw.edu.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®