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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/ataraid-list _______________________________________________ Ataraid-list mailing list Ataraid-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ataraid-list
