Hello Neil, hello everybody, I am working on improved DDF support in mdadm. I would be grateful for a review on this patch series. The main new feature is support for RAID 10 in DDF, such that md is able to interoperate with an LSI Megaraid Software RAID driver on a RAID10 array. The DDF/RAID10 support is not feature complete, but usable. Both assembly and incremental assembly work as expected. I verified that the 2+2 layout maps cleanly to that used by the LSI SW RAID stack. Meta data are saved cleanly and interpreted correctly by the LSI stack. What is yet missing is code to handle disk failures and additions. I would appreciate some guidance in that area, in particular how to test it. In the DDF Spec, RAID10 is a special case of the broad "secondary RAID level" concept. The intersection between DDF RAID 10 and md RAID 10 is tiny - just the "near" layout with an even number of disks. Fortunately this is also the only type of "secondary RAID" supported by my LSI stack, and generally the most common multilevel RAID, AFAICT. The DDF 2nd level RAID concept would be matched more closely by a different approach where md only creates the BVDs and the secondary RAID is implemented with the device mapper on top of it. But I opted for the direct mapping of DDF RAID10 to md RAID10 for several reasons: 1) dm wouldn't handle the generic "striped" and "spanned" secondary levels out-of-the box, either. 2) I wanted to take full benefit of the advanced features and performance of md RAID10 (it actually performed better than the LSI stack in a few simple benchmarks). 3) It is simpler to handle this way. 4) This is non-exclusive, code could still be added later to use dm for more "exotic" secondary DDF RAID levels. The series stars out with 3 patches I already submitted a while ago. They fix interoperability related to meta data handling, in particular DDF header locations and Sequential numbers. They are unrelated to RAID10. Patch 4..9 introduce support for DDF RAID 10. The current mdadm implementation of DDF ignores secondary level completely and stores only the BVD information in the super block, one BVD for every DDF "Virtual disk configuration record". I had to add an additional data structure to hold information about the "other BVDs" belonging to a second level RAID set. The most intersting stuff happens in container_content_ddf, which translates the DDF RAID 10 setup into md structures. Patch 10 adds some missing sanity checks in compare_super_ddf. Patch 11 extends compare_super_ddf() such that information from the new disk that is missing in the current superblock is added. This fixes a problem where mdmon would save updated meta data only on those disks that were present while mdadm was started, not on disks added later. Finally, patch 12 is a small improvement to Detail() that results in better output of mdadm -D for complex DDF setups. Regards Martin Martin Wilck (12): DDF: cleanly save the secondary DDF structure DDF: use existing locations for primary and secondary DDF structure DDF: increase seq number when writing meta data DDF: added other_bvd to struct vcl DDF: load_ddf_local: store VD conf for other BVDs DDF: container_content_ddf: change array disk search loop DDF: container_content_ddf: check for secondary RAID DDF: container_content_ddf: handle RAID layout for RAID10 DDF: __write_init_super_ddf: use correct VD conf DDF: add sanity checks in compare_super_ddf DDF: compare_super_ddf: merge local info of other superblock Detail.c: call load_container for container subarrays Detail.c | 10 +- super-ddf.c | 556 ++++++++++++++++++++++++++++++++++++++++++++++++++--------- 2 files changed, 484 insertions(+), 82 deletions(-) -- 1.7.3.4 -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
