join_superset and isw.c
Heinz Mauelshagen
heinzm at redhat.com
Tue Nov 11 18:07:30 UTC 2008
Am Montag, den 10.11.2008, 13:28 -0500 schrieb Phillip Susi:
> I've been trying to fix a bug in Ubuntu's dmraid package based on rc14
> and using a patch from mandriva to add raid10 support to isw.c, and I
> have noticed some odd things that I thought I would ask about here.
>
> I noticed that most other ataraid format handlers use join_superset() in
> format.c, which I believe is used to synchronize things like the devs
> member in the different raid set structures that get created to
> represent the various components of the overall raid set.
It joins a RAID set structure into a given superset one (if not
previously joined already), ensuring that the superset structure gets
created *if* not already existing.
> The mandriva
> patch modifies isw.c to also make use of join_superset, and in doing so,
> changed name() to have the same signature as the other format handlers,
> which is to say, it removed the struct isw_dev parameter. I now see the
> reason it did this was because join_superset is given a pointer to this
> function so the function needs to match the signature that join_superset
> expects. The problem this caused was that name() always went with the
> first isw_dev found, so a raid set with multiple volumes defined in it
> would end up failing to activate because the devices got added to the
> first volume twice instead of once to each of the two different volumes.
>
> The strange thing is that rc15 appears to have raid10 support built in,
> but it does not make use of join_superset(). This leaves me wondering a
> few things:
>
> 1) Do the other formats support multiple volumes defined within the raid
> set, and if so, how do they do so without passing a parameter to name()
> identifying the volume in question?
Most of them don't, because they only allow for a single RAID set on
their devices, but DDF1. The DDF1 metadata format handler doesn't use
join_superset() either.
>
> 2) Why does isw.c in rc15 not make use of join_superset? Is it because
> it MUST pass extra parameters to name()?
That's one reason. The main one is, that join_superset and the callbacks
it uses have to be enhanced to deal properly with multi RAID set
configurations per set of RAID devices (such as in "isw" and "ddf1").
>
> 3) Is my understanding of the structure correct? It looks like you are
> supposed to end up with one raid_set that describes the family as a
> whole, one that describes each of two raid0 components, one that
> describes the raid1 component, and then one for each of the volumes.
Yes, what you call family (eg. list of isw volumes) is the top-level one
of type t_group (ie. a RAID set grouping entity), which is *not* subject
to activation.
RAID sets hanging off type t_group top-level sets are for activation and
those can be supersets in case of eg. RAID10 mappings.
> What I'm not sure of is what raid_devs should be linked to by each of
> those raid_sets.
Only lowest level raid_sets link to raid_devs (ie. all supersets have an
empty devs list (see struct raid_set).
In case of multiple raid_sets per device (struct dev_info), all of their
raid_devs refer to the one device (see setup_rd() in the metadata format
handler.
Heinz
>
> _______________________________________________
> Ataraid-list mailing list
> Ataraid-list at redhat.com
> https://www.redhat.com/mailman/listinfo/ataraid-list
More information about the Ataraid-list
mailing list