[PATCH] Do not assemble a duplicate of a running array

[Yury Polyanskiy]

On Mon, Jul 11, 2011 at 12:57 AM, martin f krafft <madduck at debian.org>wrote:

> also sprach Yury Polyanskiy <yp at mit.edu> [2011.07.11.0304 +0200]:
> > * startup proceeds to execute /etc/init.d/mdadm-raid which runs "mdadm
> > --assemble --scan".
> > * mdadm --assemble --scan discovers the description of /dev/md/data in
> > mdadm.conf and finds a lonely /dev/sda with a matching UUID; /dev/md126
> is
> > created out of a single /dev/sda
>
> Why would it create a second MD with the same UUID as an existing
> one? I have never seen this behaviour in 7 years of mdadm
> development. Which version are you running?
>

Hi Martin! I was as surprised as you are. What happens is mdadm scans config
file, finds /dev/md/data, scans all drives and finds /dev/sda has a matching
UUID and is not busy (others are busy, since they are already part of the
assembled array).

Perhaps, this was overlooked because usually a dead drive is physically
removed (in my case it was not dead, so stayed inside with a lagging events
counter).


>
> I appreciate your work on the patch. It seems a bit large. Do you
> need to factor our __load_superblock? Or would it be possible to
> create a minimal version?
>

I factored out __load_superblock() to avoid code duplication. I thought how
to make a smaller version, but the thing is we need to read the  superblock
from a physical drive, so something like __load_superblock() must be called
from md_check_uuid(). Then I looked for the code that does it, found it in
Detail() and separated into a separate function.

Best,
Yury
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-mdadm-devel/attachments/20110711/4342c602/attachment.html>