RE: Picking up development of dmraid
Mark-Willem Jansen <[email protected]> Thu, 19 Jul 2012 21:19:59 +0200
| Newsgroups | gmane.linux.ataraid |
|---|---|
| Message-ID | <[email protected]> |
--===============0174921995738401975== Content-Type: multipart/alternative; boundary="_884b693e-8508-443d-b9a4-7b72d8763367_" --_884b693e-8508-443d-b9a4-7b72d8763367_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ryan=2C You will have to wait a while=2C I first need to learn more about the inter= ior of mdadm. I will start with reading the intel implementation. But if you can point me to other information besides source-codes=2C that w= ould be great. Greetings=2C Mark-Willem > Date: Thu=2C 19 Jul 2012 16:58:35 +0100 > From: [email protected] > To: [email protected] > CC: [email protected] > Subject: Re: Picking up development of dmraid >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 07/19/2012 03:30 PM=2C Mark-Willem Jansen wrote: > > I do not know the finer detail of mdadm=2C yet. But I saw > > super-mbr.c and super-gpt.c and and draw the conclusion=2C taken how > > dmraid handles mbr=2C that these were codes to parse mbt and gpt > > partition tables. >=20 > Ah=2C gotcha - I think this code was introduced a few years after the > external metadata support was added (not sure though=2C would have to > look in git) and is handled in the same manner as the DDF=2C Intel and > native MD metadata formats. >=20 > Unlike those formats though you cannot assemble arrays from MBR or gpt > metadata - they're only used when adding new bare devices to arrays so > that the member partitions can be used. >=20 > >> I think adding new format handlers to MD is a much better idea=3B=20 > >> the dominant formats backed by major OEMs are already using it > >> so if there's interest in the less commonly used formats I think > >> they would see much better maintenance and continued development > >> in an active project like mdadm than they would in a revived > >> dmraid. > >=20 > > So it would be time that someone(probably me) starts adding the=20 > > Promise formats used by the AMD chip-sets. >=20 > Cool! Seems like a good direction. I'd be interested in having a look > at this too. >=20 > Regards=2C > Bryn. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAlAILqoACgkQ6YSQoMYUY967mgCg1R+u1ROnHe1gEmD56gPVA4Ot > 3f8AoKtc7IKv6Sct5RIj16ovqa+rqpO5 > =3DqyIZ > -----END PGP SIGNATURE----- = --_884b693e-8508-443d-b9a4-7b72d8763367_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style><!-- .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Tahoma } --></style></head> <body class=3D'hmmessage'><div dir=3D'ltr'> Hi Ryan=2C<BR><br><BR>You will have to wait a while=2C I first need to lear= n more about the interior of mdadm.<BR><br><BR>I will start with reading th= e intel implementation.<br><BR><br><BR>But if you can point me to other inf= ormation besides source-codes=2C that would be great.<BR><br><BR>Greetings= =2C<BR><br><BR>Mark-Willem<BR><br><div>>=3B Date: Thu=2C 19 Jul 2012 16:5= 8:35 +0100<br>>=3B From: [email protected]<br>>=3B To: ataraid-list@redhat= .com<br>>=3B CC: [email protected]<br>>=3B Subject: Re: Picking up= development of dmraid<br>>=3B <br>>=3B -----BEGIN PGP SIGNED MESSAGE--= ---<br>>=3B Hash: SHA1<br>>=3B <br>>=3B On 07/19/2012 03:30 PM=2C Mar= k-Willem Jansen wrote:<br>>=3B >=3B I do not know the finer detail of m= dadm=2C yet. But I saw<br>>=3B >=3B super-mbr.c and super-gpt.c and and= draw the conclusion=2C taken how<br>>=3B >=3B dmraid handles mbr=2C th= at these were codes to parse mbt and gpt<br>>=3B >=3B partition tables.= <br>>=3B <br>>=3B Ah=2C gotcha - I think this code was introduced a few= years after the<br>>=3B external metadata support was added (not sure th= ough=2C would have to<br>>=3B look in git) and is handled in the same man= ner as the DDF=2C Intel and<br>>=3B native MD metadata formats.<br>>=3B= <br>>=3B Unlike those formats though you cannot assemble arrays from MBR= or gpt<br>>=3B metadata - they're only used when adding new bare devices= to arrays so<br>>=3B that the member partitions can be used.<br>>=3B <= br>>=3B >=3B>=3B I think adding new format handlers to MD is a much b= etter idea=3B <br>>=3B >=3B>=3B the dominant formats backed by major = OEMs are already using it<br>>=3B >=3B>=3B so if there's interest in = the less commonly used formats I think<br>>=3B >=3B>=3B they would se= e much better maintenance and continued development<br>>=3B >=3B>=3B = in an active project like mdadm than they would in a revived<br>>=3B >= =3B>=3B dmraid.<br>>=3B >=3B <br>>=3B >=3B So it would be time th= at someone(probably me) starts adding the <br>>=3B >=3B Promise formats= used by the AMD chip-sets.<br>>=3B <br>>=3B Cool! Seems like a good di= rection. I'd be interested in having a look<br>>=3B at this too.<br>>= =3B <br>>=3B Regards=2C<br>>=3B Bryn.<br>>=3B -----BEGIN PGP SIGNATUR= E-----<br>>=3B Version: GnuPG v1.4.12 (GNU/Linux)<br>>=3B Comment: Usin= g GnuPG with Mozilla - http://enigmail.mozdev.org/<br>>=3B <br>>=3B iEY= EARECAAYFAlAILqoACgkQ6YSQoMYUY967mgCg1R+u1ROnHe1gEmD56gPVA4Ot<br>>=3B 3f8= AoKtc7IKv6Sct5RIj16ovqa+rqpO5<br>>=3B =3DqyIZ<br>>=3B -----END PGP SIGN= ATURE-----<br></div> </div></body> </html>= --_884b693e-8508-443d-b9a4-7b72d8763367_-- --===============0174921995738401975== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ataraid-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/ataraid-list --===============0174921995738401975==--