Re: [Evms-devel] Possible to create a degraded RAID5 array with EVMS?

[Steve D. <st...@us...>]

"James Lee" <jam...@ho...> wrote on 11/16/2005 06:08:14 PM:

> Thanks for the reply Steve.
>
> I've retried setting up a degraded RAID5 array as described below, and
have
> hit a different error in EVMS ("*** glibc detected *** free(): invalid
next
> size (fast): 0x0819d720 ***").  Procedure was:
>
>
> 1)  Delete all md arrays and all segments from /dev/sdb (using EVMS).
> Worked fine.

Yea.

> 2)  Close and reopen EVMS to check all is still well.  It is.  Close it
down
> again.

Good.

> 3)  Using cfdisk, create two logical (not primary) partitions on /dev/sdb

> (which had just free space), 100MB each (these are /dev/sdb5 and
/dev/sdb6).
>   Mark them as type 0xfd (Linux RAID autodetect).  Save changes and again

> reload and close EVMS to check it's still happy; which it is.

Don't set the partition type to RAID autodetect.  Use the normal Linux
partition type.  The kernel MD autodetect conflicts with EVMS's discovery
and activation.  Somewhere in the documentation (I can't find it at the
moment) it should say that you should disable RAID autodetect if you are
going to use EVMS to manage your software-RAID arrays.

> 4)  Use mdadm to create a degraded RAID5 array using the following
command:
> "mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdb5 /dev/sdb6
> missing"

Looks good.

> 5)  mdadm report that this array gets created successfully (in a degraded

> state):
> james@ubuntu-fileserver:~$ sudo mdadm --detail /dev/md0
> /dev/md0:
>         Version : 00.90.01
>   Creation Time : Wed Nov 16 23:05:41 2005
>      Raid Level : raid5
>      Array Size : 192512 (188.00 MiB 197.13 MB)
>     Device Size : 96256 (94.00 MiB 98.57 MB)
>    Raid Devices : 3
>   Total Devices : 2
> Preferred Minor : 0
>     Persistence : Superblock is persistent
>
>     Update Time : Wed Nov 16 23:05:41 2005
>           State : clean, degraded
> Active Devices : 2
> Working Devices : 2
> Failed Devices : 0
>   Spare Devices : 0
>
>          Layout : left-symmetric
>      Chunk Size : 64K
>
>            UUID : 6f0fa83a:ae0b4a99:a199ce36:9e21815c
>          Events : 0.4
>
>     Number   Major   Minor   RaidDevice State
>        0       8       21        0      active sync
/dev/.static/dev/sdb5
>        1       8       22        1      active sync
/dev/.static/dev/sdb6
>        2       0        0        -      removed
>
> 6)  Start EVMS GUI.  Gives me a warning about /md/md0 being in a degraded

> state (which is fine).  It doesn't give me the option to create an EVMS
> volume from the /md/md0 array (which is not good).  It sees the array,
and
> reports it as both degraded and corrupted (it shouldn't be, right?).

Correct.  EVMS should discover the array is degraded, but it should not be
corrupt.

> 7)  Close down EVMS and restart it.  Again, I get a warning about the
array
> being degraded.  Now I do have the option to create a volume from the
array.
>   On trying to do this however, I get the following error message:
> *** glibc detected *** free(): invalid next size (fast): 0x0819d720 ***
> and EVMS hangs completely.
>
> I've attached a gzipped copy of the evms-engine.log file.
>
> Hope this helps...

It does.  The last thing in the log is a call to raid5_free_private_data()
in the MD plug-in.  That function has a bunch of calls to free memory.  I
suspect one of those is going bad.  It is not apparent from the code which
one is bad.  In fact, for each call to free memory, the code checks for a
NULL pointer first, frees the non-NULL pointer, and then sets the pointer
to NULL.  Looks safe to me.  My guess is there is some code elsewhere that
has already freed some memory but has not set the pointer to NULL,
resulting in a double free.

EVMS has some memory debugging code, but it has to be built in.  Can you do
me the favor of another run?  Rebuild EVMS with the debug support.
./configure --with-debug <your-other-options>
make clean install

Then run evmsgui with the debug level set to "everything", e.g., "evmsgui
-d everything".  That will generate a rather large log file since it will
log *everything*, which includes all calls to allocate and free memory.
I'm hoping the memory allocation debugging code will catch a double free
and that the log will contain the trace information to find out who did it.

> What is the relationship between the EVMS MD plugin and mdadm by the way?

> Do they use the same code, or are they entirely different programs that
> interface in their own way with the Linux RAID driver?  Should arrays
> created by mdadm and array created by EVMS be identical once they have
been
> created?

EVMS and mdadm are entirely different programs that interface in their own
way with the Linux RAID driver.  Naturally, they share common knowledge
about the on-disk data structures and the behavior of the MD code in the
kernel.  Arrays created by mdadm should be understood by EVMS and vice
versa.

Steve D.