Re: Picking up development of dmraid
Heinz Mauelshagen <[email protected]> Thu, 19 Jul 2012 10:26:49 +0200
| Newsgroups | gmane.linux.ataraid |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============7438200970519232142== Content-Type: multipart/alternative; boundary="------------090404000108050507020401" This is a multi-part message in MIME format. --------------090404000108050507020401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/18/2012 11:08 AM, Danny Wood wrote: > Hi Mark-Willem Jansen > > You may want to speak with Phillip Susi of the Ubuntu Dmraid team. > He built a set of patches a long while ago that I don't think got > included in the stable dmraid. > He knows the ins and outs of dmraid and has spends a lot of time bug > fixing during Ubuntu release cycles. > > I think the main reason that this project has died is because it is a > very niche market. Seconded WRT the niche market. > It's usually only used by the people who run a dual boot with Windows > as Mdadm is far superior for pure Linux installs. The later is exactly why things move to MD and eg. we're doing a device-mapper target wrapper to access the MD kernel runtime in order to make it accessible in LVM. Because the MD runtime has the long established field record it has, major FAKERAID OEMs decided to use it (namly Intel with their Intel Matrix RAID, isw in dmraid). mdadm gained external metadata format support along the lines of dmraid to allow for that and thus supports isw for long time now. As a result of that, Red Hat decided to not further develop dmraid. Actually we already asked publically, if dmraid is still mandatory to support the other metadata formats than DDF, Intel Matrix RAID and MD, which are supported by mdadm now anyway. No arguments it's still needed resulted from that so far. > > Also GPT can already be used on top of dmraid, as far as I know you > use dmraid to initialise the block devs and kpartx to deal with > partitions. There's no need to have code duplication for partitioinig support in another tool. For the record: the DOS partitioning support got added way back in time before kpartx addressed it (and never got pulled out). So use kpartx for activating partitionins on RAID sets. The most important question (as mentioned above) still persists though: is dmraid still needed or is any further development adequate to support the Adaptec, Highpoint, Jmicron, LSI, NVidia, Promise, Silicon Image and VIA metadata formats? Are they still being used that much in the field or are users just happy with dmraid access to those in their mixed Linux/Windows environments? Requirement for pure Linux environment is MD/LVM anyway. We better get field feedback which we didn't get so far to answer that question. Heinz > > Good luck and best regards, > Danny > > > On 18/07/12 09:20, Mark-Willem Jansen wrote: >> Dear dmraid developers, >> >> Sometime in this mail-list it was said that the program dmraid was in >> maintaining mode and not further developed anymore. In the meantime >> the dm-developement team has put out new dm-target, which can be used >> by the tool. >> >> I would like to fork the latest RC and put on github, to continue >> developing the tool. I will give it a slightly new name, so people >> will not confuse it with the original. My plan is to add the support >> for new dm-targets and also implement more partition tables, starting >> with GPT. >> >> I am not really good at generating new names, but here are some ideas. >> >> dmraid-fbmw (forked by Mark-Willem) >> dmraid-fu (follow-up) >> dmraid-ext (extended version) >> >> So my question which name you think is a good one for the forked? >> >> And who can I connect if I have some questions about the tool. >> >> Greetings, >> >> Mark-Willem Jansen >> >> >> >> _______________________________________________ >> Ataraid-list mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/ataraid-list > > > > > _______________________________________________ > Ataraid-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/ataraid-list --------------090404000108050507020401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> On 07/18/2012 11:08 AM, Danny Wood wrote:<br> <blockquote cite="mid:[email protected]" type="cite"> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> Hi Mark-Willem Jansen<br> <br> You may want to speak with Phillip Susi of the Ubuntu Dmraid team.<br> He built a set of patches a long while ago that I don't think got included in the stable dmraid.<br> He knows the ins and outs of dmraid and has spends a lot of time bug fixing during Ubuntu release cycles.<br> <br> I think the main reason that this project has died is because it is a very niche market.<br> </blockquote> <br> Seconded WRT the niche market.<br> <br> <blockquote cite="mid:[email protected]" type="cite"> It's usually only used by the people who run a dual boot with Windows as Mdadm is far superior for pure Linux installs.<br> </blockquote> <br> The later is exactly why things move to MD and eg. we're doing a device-mapper target wrapper<br> to access the MD kernel runtime in order to make it accessible in LVM.<br> <br> Because the MD runtime has the long established field record it has, major FAKERAID OEMs decided<br> to use it (namly Intel with their Intel Matrix RAID, isw in dmraid).<br> mdadm gained external metadata format support along the lines of dmraid to allow for that and<br> thus supports isw for long time now.<br> <br> As a result of that, Red Hat decided to not further develop dmraid. Actually we already asked publically,<br> if dmraid is still mandatory to support the other metadata formats than DDF, Intel Matrix RAID and MD,<br> which are supported by mdadm now anyway.<br> <br> No arguments it's still needed resulted from that so far.<br> <br> <blockquote cite="mid:[email protected]" type="cite"> <br> Also GPT can already be used on top of dmraid, as far as I know you use dmraid to initialise the block devs and kpartx to deal with partitions.<br> </blockquote> <br> There's no need to have code duplication for partitioinig support in another tool.<br> For the record: the DOS partitioning support got added way back in time before kpartx addressed it<br> (and never got pulled out).<br> <br> So use kpartx for activating partitionins on RAID sets.<br> <br> <br> The most important question (as mentioned above) still persists though: is dmraid still needed or<br> is any further development adequate to support the Adaptec, Highpoint, Jmicron, LSI, NVidia, Promise,<br> Silicon Image and VIA metadata formats? Are they still being used that much in the field or are users<br> just happy with dmraid access to those in their mixed Linux/Windows environments?<br> Requirement for pure Linux environment is MD/LVM anyway.<br> <br> We better get field feedback which we didn't get so far to answer that question.<br> <br> Heinz<br> <br> <blockquote cite="mid:[email protected]" type="cite"> <br> Good luck and best regards,<br> Danny<br> <br> <br> <div class="moz-cite-prefix">On 18/07/12 09:20, Mark-Willem Jansen wrote:<br> </div> <blockquote cite="mid:[email protected]" type="cite"> <style><!-- .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 10pt; font-family:Tahoma } --></style> <div dir="ltr"> Dear dmraid developers,<br> <br> Sometime in this mail-list it was said that the program dmraid was in maintaining mode and not further developed anymore. In the meantime the dm-developement team has put out new dm-target, which can be used by the tool.<br> <br> I would like to fork the latest RC and put on github, to continue developing the tool. I will give it a slightly new name, so people will not confuse it with the original. My plan is to add the support for new dm-targets and also implement more partition tables, starting with GPT.<br> <br> I am not really good at generating new names, but here are some ideas.<br> <br> dmraid-fbmw (forked by Mark-Willem)<br> dmraid-fu (follow-up)<br> dmraid-ext (extended version)<br> <br> So my question which name you think is a good one for the forked?<br> <br> And who can I connect if I have some questions about the tool.<br> <br> Greetings,<br> <br> Mark-Willem Jansen<br> <br> </div> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ Ataraid-list mailing list <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/ataraid-list">https://www.redhat.com/mailman/listinfo/ataraid-list</a></pre> </blockquote> <br> <br> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ Ataraid-list mailing list <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/ataraid-list">https://www.redhat.com/mailman/listinfo/ataraid-list</a></pre> </blockquote> <br> </body> </html> --------------090404000108050507020401-- --===============7438200970519232142== 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 --===============7438200970519232142==--