Picking up development of dmraid

Mark-Willem Jansen markwillem at hotmail.com
Thu Jul 19 13:33:27 UTC 2012


Hi Heinz,

Concerning the partitioning support. I now feel that kpartx or (partx which could be made compatible) would be the way to go in stead of dmraid. So it would be a good idea to remove the partitioning support from dmraid.  This will mean the package maintainer will need to make dmraid dependent on kpartx for it to work.

One remark on this: I found that on Debian to make kpartx work with dmraid during boot, one needs to make some changes to the multipath-tools packages.

On a side note: Why does mdadm support MBR and GPT?

Concerning the usage of mdadm instead of dmraid. Me and probably and a large amount of AMD users will have a AMD chip-set which means a Promise FAKERAID controller. So in my idea I had two options update dmraid to work with the dm-raid target(probably the device-mapper target wrapper you are talking about) to setup my RAID-5 or add support for the Promise metadata format to mdadm. I picked the former as the code of dmraid look easier to understand. ;-)

If you say that adding a super-promise.c to mdadm is doable, I could change my mind.

Just one last question I never really got an answer to. Can one use mdadm on a dual boot system(MS and Linux) were the RAID partitions are shared? In other words will mdadm leave the metadata on the disks unchanged or in a state the the MS drivers can still recognize the RAID.

Would it be an idea to clean-up dmraid? Remove what is not needed anymore, or does not fit the purpose of the tool.

Kind regards,


Mark-Willem

Date: Thu, 19 Jul 2012 10:26:49 +0200
From: heinzm at redhat.com
To: ataraid-list at redhat.com
Subject: Re: Picking up development of dmraid


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

      

      

      
      

      _______________________________________________
Ataraid-list mailing list
Ataraid-list at redhat.com
https://www.redhat.com/mailman/listinfo/ataraid-list
    
    

  


_______________________________________________
Ataraid-list mailing list
Ataraid-list at redhat.com
https://www.redhat.com/mailman/listinfo/ataraid-list 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/ataraid-list/attachments/20120719/8d346b9f/attachment.htm>


More information about the Ataraid-list mailing list