19 Jul 2012 16:30
RE: Picking up development of dmraid
Mark-Willem Jansen <markwillem <at> hotmail.com>
2012-07-19 14:30:30 GMT
2012-07-19 14:30:30 GMT
Hi Bryn,
Thank for the comments. The complete picture is slowly evolving.
Thank for the comments. The complete picture is slowly evolving.
> > 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.
>
> It already does in most (all?) distributions that ship it.
Probably Debian is legging behind here, as dmraid is unmaintained AFAIK.
> > 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.
>
> What were the changes? The kpartx command is part of multipath-tools
> and although it's common to have it in a separate sub-package (all
> current Red Hat and Fedora distros do this) they are part of the same
> project upstream.
On Debain there is a package called multipath-tools-boot, which will add multipath, kpartx, and dmsetup to the initramfs. But I did not liked what multipath was doing to the /dev/mapper directory. So I mimicked ubuntu and made a separate package kpartx-boot. So when I come to think of it, maybe it worked out of the debian-box, apart from some warnings during boot.
> > On a side note: Why does mdadm support MBR and GPT?
>
> Not sure what you're asking here? The kernel MD driver creates
> partitionable devices so you can use any of the label formats that are
> enabled in the kernel you're running (although really, MBR and GPT are
> the only ones that make sense for most systems today).
I do not know the finer detail of mdadm, yet. But I saw super-mbr.c and super-gpt.c and and draw the conclusion, taken how dmraid handles mbr, that these were codes to parse mbt and gpt partition tables.
> I think adding new format handlers to MD is a much better idea; 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.
So it would be time that someone(probably me) starts adding the Promise formats used by the AMD chip-sets.
> > 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.
>
> Assuming that MD supports the format handler you need: yes.
That is nice to hear.
> I think the time would be better spent learning or contributing to MD
> and mdadm development and adding support for other format handlers
> that have users wanting native Linux support.
Then it is time for me to start reading into mdadm.
Kind regards,
Mark-Willem
> > support from dmraid. This will mean the package maintainer will
> > need to make dmraid dependent on kpartx for it to work.
>
> It already does in most (all?) distributions that ship it.
Probably Debian is legging behind here, as dmraid is unmaintained AFAIK.
> > 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.
>
> What were the changes? The kpartx command is part of multipath-tools
> and although it's common to have it in a separate sub-package (all
> current Red Hat and Fedora distros do this) they are part of the same
> project upstream.
On Debain there is a package called multipath-tools-boot, which will add multipath, kpartx, and dmsetup to the initramfs. But I did not liked what multipath was doing to the /dev/mapper directory. So I mimicked ubuntu and made a separate package kpartx-boot. So when I come to think of it, maybe it worked out of the debian-box, apart from some warnings during boot.
> > On a side note: Why does mdadm support MBR and GPT?
>
> Not sure what you're asking here? The kernel MD driver creates
> partitionable devices so you can use any of the label formats that are
> enabled in the kernel you're running (although really, MBR and GPT are
> the only ones that make sense for most systems today).
I do not know the finer detail of mdadm, yet. But I saw super-mbr.c and super-gpt.c and and draw the conclusion, taken how dmraid handles mbr, that these were codes to parse mbt and gpt partition tables.
> I think adding new format handlers to MD is a much better idea; 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.
So it would be time that someone(probably me) starts adding the Promise formats used by the AMD chip-sets.
> > 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.
>
> Assuming that MD supports the format handler you need: yes.
That is nice to hear.
> I think the time would be better spent learning or contributing to MD
> and mdadm development and adding support for other format handlers
> that have users wanting native Linux support.
Then it is time for me to start reading into mdadm.
Kind regards,
Mark-Willem
_______________________________________________ Ataraid-list mailing list Ataraid-list <at> redhat.com https://www.redhat.com/mailman/listinfo/ataraid-list
RSS Feed