RE: Picking up development of dmraid
Mark-Willem Jansen <[email protected]> Thu, 19 Jul 2012 16:30:30 +0200
| Newsgroups | gmane.linux.ataraid |
|---|---|
| Message-ID | <[email protected]> |
--===============6177085030653147331==
Content-Type: multipart/alternative;
boundary="_9723dc5f-cbc3-4759-adb3-4e4c86f4faf7_"
--_9723dc5f-cbc3-4759-adb3-4e4c86f4faf7_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Bryn=2C
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.
>=20
> It already does in most (all?) distributions that ship it.
Probably Debian is legging behind here=2C as dmraid is unmaintained AFAIK.
> > One remark on this: I found that on Debian to make kpartx work
> > with dmraid during boot=2C one needs to make some changes to the=20
> > multipath-tools packages.
>=20
> 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=2C which will add =
multipath=2C kpartx=2C and dmsetup to the initramfs. But I did not liked wh=
at multipath was doing to the /dev/mapper directory. So I mimicked ubuntu a=
nd made a separate package kpartx-boot. So when I come to think of it=2C ma=
ybe it worked out of the debian-box=2C apart from some warnings during boot=
.
> > On a side note: Why does mdadm support MBR and GPT?
>=20
> 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=2C MBR and GPT are
> the only ones that make sense for most systems today).
I do not know the finer detail of mdadm=2C yet. But I saw super-mbr.c and s=
uper-gpt.c and and draw the conclusion=2C taken how dmraid handles mbr=2C t=
hat these were codes to parse mbt and gpt partition tables.
> I think adding new format handlers to MD is a much better idea=3B 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 for=
mats used by the AMD chip-sets.=20
> > 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.
>=20
> 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=2C
Mark-Willem
=
--_9723dc5f-cbc3-4759-adb3-4e4c86f4faf7_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
</head>
<body class=3D'hmmessage'><div dir=3D'ltr'>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
<div dir=3D"ltr">Hi Bryn=2C<br><br>Thank for the comments. The complete pic=
ture is slowly evolving.<br><br><div><div id=3D"SkyDrivePlaceholder"></div>=
>=3B >=3B dmraid. So it would be a good idea to remove the partitioning=
<br>>=3B >=3B support from dmraid. This will mean the package maintain=
er will<br>>=3B >=3B need to make dmraid dependent on kpartx for it to =
work.<br>>=3B <br>>=3B It already does in most (all?) distributions tha=
t ship it.<br><br>Probably Debian is legging behind here=2C as dmraid is un=
maintained AFAIK.<br><br>>=3B >=3B One remark on this: I found that on =
Debian to make kpartx work<br>>=3B >=3B with dmraid during boot=2C one =
needs to make some changes to the <br>>=3B >=3B multipath-tools package=
s.<br>>=3B <br>>=3B What were the changes? The kpartx command is part o=
f multipath-tools<br>>=3B and although it's common to have it in a separa=
te sub-package (all<br>>=3B current Red Hat and Fedora distros do this) t=
hey are part of the same<br>>=3B project upstream.<br><br>On Debain there=
is a package called multipath-tools-boot=2C which will add multipath=2C kp=
artx=2C and dmsetup to the initramfs. But I did not liked what multipath wa=
s doing to the /dev/mapper directory. So I mimicked ubuntu and made a separ=
ate package kpartx-boot. So when I come to think of it=2C maybe it worked o=
ut of the debian-box=2C apart from some warnings during boot.<br><br>>=3B=
>=3B On a side note: Why does mdadm support MBR and GPT?<br>>=3B <br>&=
gt=3B Not sure what you're asking here? The kernel MD driver creates<br>>=
=3B partitionable devices so you can use any of the label formats that are<=
br>>=3B enabled in the kernel you're running (although really=2C MBR and =
GPT are<br>>=3B the only ones that make sense for most systems today).<br=
><br>I do not know the finer detail of mdadm=2C yet. But I saw super-mbr.c =
and super-gpt.c and and draw the conclusion=2C taken how dmraid handles mbr=
=2C that these were codes to parse mbt and gpt partition tables.<br><br>>=
=3B I think adding new format handlers to MD is a much better idea=3B the<b=
r>>=3B dominant formats backed by major OEMs are already using it so if<b=
r>>=3B there's interest in the less commonly used formats I think they wo=
uld<br>>=3B see much better maintenance and continued development in an a=
ctive<br>>=3B project like mdadm than they would in a revived dmraid.<br>=
<br>So it would be time that someone(probably me) starts adding the Promise=
formats used by the AMD chip-sets. <br><br>>=3B >=3B Just one last que=
stion I never really got an answer to. Can one<br>>=3B >=3B use mdadm o=
n a dual boot system(MS and Linux) were the RAID<br>>=3B >=3B partition=
s are shared? In other words will mdadm leave the metadata<br>>=3B >=3B=
on the disks unchanged or in a state the the MS drivers can still<br>>=
=3B >=3B recognize the RAID.<br>>=3B <br>>=3B Assuming that MD suppor=
ts the format handler you need: yes.<br><br>That is nice to hear.<br><br>&g=
t=3B I think the time would be better spent learning or contributing to MD<=
br>>=3B and mdadm development and adding support for other format handler=
s<br>>=3B that have users wanting native Linux support.<br><br>Then it is=
time for me to start reading into mdadm.<br><br>Kind regards=2C<br><br>Mar=
k-Willem<br></div></div>
</div></body>
</html>=
--_9723dc5f-cbc3-4759-adb3-4e4c86f4faf7_--
--===============6177085030653147331==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Ataraid-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/ataraid-list
--===============6177085030653147331==--