join_superset and isw.c

Heinz Mauelshagen heinzm at
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


> _______________________________________________
> Ataraid-list mailing list
> Ataraid-list at

More information about the Ataraid-list mailing list