On Mon, Mar 22, 2010 at 09:56:01PM -0600, Randy Terbush wrote:
quoted text
>Having a go at building a raid5 array using the new imsm support and
>having good luck keeping drives in the array, etc. Nice work. I have a
>few questions though as I am having some trouble figuring out how to
>properly start this container.
>
># mdadm --version
>mdadm - v3.1.2 - 10th March 2010
>
># mdadm -Es
>ARRAY metadata=imsm UUID=30223250:76fd248b:50280919:0836b7f0
>ARRAY /dev/md/Volume0 container=30223250:76fd248b:50280919:0836b7f0
>member=0 UUID=8a4ae452:da1e7832:70ecf895:eb58229c
>
># ls -l /dev/md/
>total 0
>lrwxrwxrwx 1 root root 6 Mar 22 20:54 0 -> ../md0
>lrwxrwxrwx 1 root root 8 Mar 22 20:54 127 -> ../md127
>lrwxrwxrwx 1 root root 8 Mar 22 20:54 Volume0_0 -> ../md127
>
>As you can see, the name for the link in /dev/md does not agree with
>the name that the Examine is coming up with.
please read mdadm.conf manpage, under the section "HOMEHOST"

quoted text
>Is it better to just forgo the ARRAY statements and go with an AUTO +imsm?
>
>And last, does the concept of a write-intent bitmap make sense on an
>imsm container? If so, I get a segv if trying to run mdadm /dev/mdX
>-Gb internal on either device.

i don't believe it makes sense at all, surely imsm do not support an
internal bitmap (no provisioning for it in the metadata)

The attached patch completely disables bitmap support for arrays with
externally managed metadata.

on a style note, i do not like having the struct superswitch, which is a
collection of function pointers which is then instanced with only some
of the pointers initialized, it forces having to check at runtime if
they are or not.
a possible solution would be to wrap every call of these into a macro
that check for NULL before, but how do you return the correct return
type from that?

L.

-- 
Luca Berra -- bluca@comedia.it
          Communication Media & Services S.r.l.
   /"\
   \ /     ASCII RIBBON CAMPAIGN
    X        AGAINST HTML MAIL
   / \