Re: Picking up development of dmraid

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.