Andree Leidenfrost said on Sat, May 06, 2006 at 10:40:28AM +1000: > Sorry it has taken my longer than announce but here is finally my > response:
Hey no pb. You're generally quicker than what I can handle in term of
charge and load, so great !!
> On Sun, 2006-04-30 at 22:41 +0200, Bruno Cornec wrote:
> > > 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.
>
> As a side note, the system default if you don't specify anything is 64k.
Ok so in the conf file, I'll need to put 64k by default + an example
line to show that it can be changed to 4k e.g.
> Ok, I'll include multipath support than. It's already in parse_mdstat()
> and shouldn;t be too hard to add to the rest.
Super :-)
It could be part of a further version of course.
> Ok, no worries. Internationalisation sounds great by the way!
Yes. It's now in stable (but not in tthe 2.0.8 I created. Marketing
choice ;-)
So a side remark, if you want to add messages, please look at how they
are done now (in short we call the "_" function before sending a msg.
e.g. printf(_("Hello World\n"));
And it will allow you to do the german .po file ;-)
The person who did that work as already provided a fr.po.
> > > 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.
So, I'd say, put it in stable *and if you have time 2.0.8 *and* trunck.
I know, it's a bit too much, but my plans are to keep 2.0.8 as the
stable version, potentially correcting some bugs on it for a 2.0.9,
2.0.10, but no evolution. Stable in the Debian sense of the word ;-)
stable will become 2.2.0 with intl, conf files, and I hope /dev/mapper
support.
If I have time, and not too many things happen in the mean time, even
truck could become 2.2.0, with on top a new memory management system !!
> > You're testing first raidstart, and then assume that it's lvmv1
>
> Erm, I'm testing for raidstart and in its absence use mdrun. I have not
> touches any lvm related bits, so if lvm1 is assumed than that's
> unchanged from before. (RAID and LVM are independent, no?)
Heu yes. I tend to make a confusion between LVM v1/2 and Raid v1/mdadm.
Sorry for that, my fault.
I was thinking to systems that could mix Raid v1 (with raidtools) and
Raid v2 (with mdadm). I'm not even sure it exists. But for compatibility
purposes, a system could live and implement booth during time.
Hey wait, I'm not even sure it can work. An idea on that ?
Anyway It could be a further improvement as you suggest. I tend to want
everything from start. I'm probably still too young ;-)
> If we store it in a conf file, that would have to be read by mindi,
> mondoarchive, mondorestore and init.
Yes, that's the plan.
I have begin to code the mindi conf file for the moment (easiest as it's
done in shell and sourced in fact). But that content has also to be read
by mondoarchive as it needs some parameters to work corectly (temporary
path such as our /var/cache evolution).
I'm not so sure for the restore part, as we already hhave a conf file
for that, and everything should be there. So if things are currently
missing, I'll have to add them.
> Can we maybe phase it in? I.e. could we use the 'look for raidtools2
> programs and only use mdadm in their absence'-approach for now and
> revisit inclusion into the conf file later on?
I suppose you meant look for raid1 and if not mdadm ?
Yes I agree with you. Pragmatism is on your side ;-) (propably the
german quality compared to the french idealism :-)
> <me, slapping my forehead> Of course, memory needs to be freed! Thanks a
> lot for pointing that out! I hope the updated attached version is
> correct in regards to that (please tell me if it's still not good!)...
I need to be useful sometimes ;-)
I think the new patch is just what we need.
Please commit it asap as I promised to create the 2.0.8 version this
week end, and as I won't be available next week for package production,
it would be great if I could make it now.
> ...and it also inlcude the sync and wait and implements most of the
> missing bits.
Perfect.
Thanks again,
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
pgpKqykpgQ1JL.pgp
Description: PGP signature
