-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/19/2012 02:33 PM, Mark-Willem Jansen wrote: > 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 The partx command only works for devices that use the in-kernel partition support (IDE, SCSI, MD, cciss, loop etc.). Device-mapper devices are not partitionable which is why kpartx was written in the first place. > 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. > 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 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). > 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. 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. Aside from the other matters MD and mdadm are well-integrated in every modern distro. Although some releases managed to get dmraid to work well out of the box most others did not and it caused quite some pain for users trying to get it working. > 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. All drivers (whether user/kernel on Linux or Windows) need to respect the requirements of the on-disk formats and leave them in an appropriate state on shutdown. That said, a RAID subsystem also needs to be robust and to tolerate sudden failures so it's also true that both sides need to be tolerant in dealing with a system in a failed state (it's Postel's law again: "be conservative in what you do, be liberal in what you accept from others"). > Would it be an idea to clean-up dmraid? Remove what is not needed > anymore, or does not fit the purpose of the tool. 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. Regards, Bryn. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAIE3QACgkQ6YSQoMYUY95ejQCgtePJacDOuDtRmJ+HDlDRzH7W GrkAoKIQ+J2rZB8P1I+UpgKhH+kuvJsY =Zluc -----END PGP SIGNATURE----- _______________________________________________ Ataraid-list mailing list Ataraid-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ataraid-list
