On Tue, Jun 16, 2009 at 12:11 PM, Heinz Mauelshagen<heinzm@xxxxxxxxxx> wrote: > dmraid supports 11 different metadata formats for various ATARAID vendor > specific solutions plus DDF1: > > asr : Adaptec HostRAID ASR (0,1,10) > ddf1 : SNIA DDF1 (0,1,4,5,linear) > hpt37x : Highpoint HPT37X (S,0,1,10,01) > hpt45x : Highpoint HPT45X (S,0,1,10) > isw : Intel Software RAID (0,1,5,01) > jmicron : JMicron ATARAID (S,0,1) > lsi : LSI Logic MegaRAID (0,1,10) > nvidia : NVidia RAID (S,0,1,10,5) > pdc : Promise FastTrack (S,0,1,10) > sil : Silicon Image(tm) Medley(tm) (0,1,10) > via : VIA Software RAID (S,0,1,10) > > 9 of those still need porting/testing/... to/with MD external metadata > support after the Intel IMSM MD port has settled, hence Red Hat is going > to continue to support dmraid. What I am personally interested in is a way for the dmraid userspace to reuse time proven md kernel infrastructure where it makes sense. Yes, there are benefits to porting the metadata formats to mdadm, but the point is that there is no immediate need, or even eventual need, to to do this work. dmraid already knows how to convert all these formats into a common dmsetup table format, and md already has knobs for userspace to create raid arrays from the same information. Can we not meet in the middle to allow at least dm-raid5 arrays to use md-raid5? Put another way do we need ~5000 new lines of kernel code to support all the functionality that dmraid requires? What happens when one of these formats wants to add raid6, more code duplication? Can we incrementally extend md-raid to cover the unmet needs of dmraid, what extensions are required? > That being said: once the future work on a unified virtual block device > infrastructure is production ready, we're open to use that. That is the end game, but there are more cooperation opportunities along the way. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
