Andree Leidenfrost said on Sat, Apr 29, 2006 at 05:32:55PM +1000:

> Please find attached a patch that implements mdadm support whilst fully
> retaining raidtools2 support. 

Many thanks for your work in this Andree !

> With the changes detailed in the patch, I
> have just successfully archived and restored a RAID1 and a RAID0 array
> consisting of two drives each on Debian sid amd64, but I expect all
> Linux distribution with mdadm to work as well (famous last words ;-) ).

Great !

> After much going back and forth I have decided to extend what is already
> there rather than recode much of the RAID functionality. The reasons are
> mainly that I have only limited time and wanted results rather sooner
> than later but even more so that I didn't want to change the raidtools2
> side of things because I can't/won't test this and I didn't want to
> spend any effort on raidtools2 because it's officially deprecated (cf.
> http://people.redhat.com/mingo/raidtools/).

No problem. That's a wise decision I think.

> With this said, the patch utilises existing capabilities for
> parsing /proc/mdstat and for reading and writing /etc/raidtab. mdadm
> works without a config file and even 'mdadm --detail --scan --verbose'
> does not give all the (relevant) information that can be gathered from
> mdstat. I could have come up with a new file (format), but I think
> raidtab is fine (it shouldn't be in /etc really). I am introducing a new
> function create_raid_device_via_mdadm() that will create a single RAID
> array using mdadm and that gets called in format_device() in case mkraid
> cannot be found. Same goes for 'mdadm -S' versus raidstop. An equivalent
> for raidstart is not really required as 'mdadm --create' starts the
> array straight away.
> 
> There are limitations (pre-existing, not introduced by my changes):
> - chunk size is hard coded to 4k

Onc my set of conf files work, please remind us to put that in it.

> - spare devices are ignored
> - the parity algorithm is ignored
> - multipath is not supported

Ok.

> To overcome these limitations, I will need to change some data
> structures and expand the mdstat parser - in fact, I have already
> written an experimental stand-alone parser for this purpose. I'm not
> sure whether multipath is worth it; it is not even really a RAID level.

No, but it's extremely useful for HA solutions. So if it's not a big
effort, I'd like to see it one day.

> Further, I had to include a few more modules for RAID in mindi and init
> needed a little change.

No pb. I'll commit those changes right now, as they are obvious

> Finally, device mapper is not supported. I understand you are working on
> this, so I haven't looked into it.

Well I'll work on it, when I'm done with all the other patches I have to
integrate (internationalization !!! done by an old relative, and also
Labeled swap fs). It won't be in 2.0.8, but in the next, I hope, which
should be 2.2.0

> It would be great if you could let me know what you think, in particular
> whether you'd be sufficiently happy for this to go into the next stable
> version.

patch mindi: taken and applied.
patch init: I have a question:
You're testing first raidstart, and then assume that it's lvmv1
What about if both tools were installed ? Couldn't we get it more surely
from another parameter ? Shouldn't we store it and pass it throught our
conf file to init ?

No problem, OTOH with the patch itself

patch mondo-prep.c : when you use asprintf, the devices string is
allocated. So before re-using it, you need to call paranoid_free on it.
If not, we're creating memory leaks. In your case, you need 2 variables.
Take an example in trunk to see how to deal with it.
You also have the same problem with program.

That's why it takes time to do that in trunk :-))

Maybe the sync could also be kept for mdadm ? Just to let time to the
system to flush al the buffers.

I would take the opportunity that you test mkraid vs mdadm to create an
option somewhere that we could use in init. WDYT ?

Greetings,
Bruno.
-- 
Linux Profession Lead EMEA  / Open Source Evangelist \        HP C&I EMEA IET
http://www.mondorescue.org / HP/Intel Solution Center \  http://hpintelco.net
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

Attachment: pgpwR3nSTHgvx.pgp
Description: PGP signature

Reply via email to