On Sun, 2006-04-30 at 22:41 +0200, Bruno Cornec wrote: > 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 -- Andree Leidenfrost Sydney - Australia
signature.asc
Description: This is a digitally signed message part
