RE: Picking up development of dmraid

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Bryn,

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

[Index of Archives]     [Linux RAID]     [Linux Device Mapper]     [Linux IDE]     [Linux SCSI]     [Kernel]     [Linux Books]     [Linux Admin]     [GFS]     [RPM]     [Yosemite Campgrounds]     [AMD 64]

  Powered by Linux