Hi John, Great stuff, thanks a lot for your testing and your feedback!
So, it looks like we can work around the issues by changing some of the hardcoded parameters. Hopefully, this keep us going until we can make this all dynmic. Obviously, I'll be most interest in any further test results you obtain. Keep it up & best regards, Andree PS: I'm away for the week and will thus only respond sporadically. ---- John Nelson <[EMAIL PROTECTED]> wrote: > Hi Andree, > > This past weekend has been my first opportunity to work on a new build. > > I did a new package build with the following change to libmondo-tools.c: > > (IS_THIS_A_STREAMING_BACKUP(bkpinfo->backup_media_type) ? 16 : 16) * 1024; > > With that change only, I was able to run a complete backup, boot from the CD > created by Mindi, and > successfully run a full verify in disaster recovery mode. > > I didn't note the exact number, but Mondo created ~1700 afio archives > containing 41794099k of > data. > > I'm planning on trying some of the other changes that were discussed, but it > will take time. > > Thanks, > > John Nelson > > --- Andree Leidenfrost <[EMAIL PROTECTED]> wrote: > > > Hi Bruno, > > > > Thanks a lot for your feedback! > > > > On Sat, 2006-06-24 at 18:44 +0200, Bruno Cornec wrote: > > > Andree Leidenfrost said on Tue, Jun 13, 2006 at 01:04:58AM +1000: > > > > > > > [Bruno: Would be great if you could comment on this one. Looks to me > > > > like we may only have to bump up a number, but maybe there are > > > > implications that I'm not aware off...] > > > > > > Ok. > > > > > > > Thanks a lot for your bug report and your analysis of the problem. I > > > > don;t have any experience with tapes and Mondo Rescue, but I can confirm > > > > that the following is still even in the latest SVN in > > > > mondo/common/my-stuff.h: > > > > > > > > #define MAX_TAPECATALOG_ENTRIES 4096 ///< The maximum number of > > > > entries > > > > in the tape catalog. > > > > > > > > So, the question would be what a reasonable value for this couldlook > > > > like. Would 65536 be ok? > > > > > > > > > > The problem I see is that mondo will then create an array of 65k > > > structuresi > > > > > > ./mondo/mondo/common/mondostructures.h: struct mountlist_line > > > el[MAX_TAPECATALOG_ENTRIES]; > > > ./mondo/mondo/common/mondostructures.h: struct s_tapecat_entry > > > el[MAX_TAPECATALOG_ENTRIES]; > > > > Hm, I see what you mean, mountlist_line is 640 bytes + 1 long long int, > > that's certainly too big to go to 65k entries. (s_tapecat_entry is much > > smaller.) > > > > > that's where my new work on dynamic memory allocation will definitively > > > help. I know, but it's not ready for prime time yet :-( > > > > Yeah, no worries. I suppose we just need to figure out whether we can > > find an interim solution for now. > > > > > I fear that by increasing that way we consume a lot of memory which > > > wwill be most of the time useless, creating other types of bugs. > > > > Agreed. > > > > > Do we need to go from 4096 to 65k directly. Isn't there a middle point > > > which could solve the issue as well as limit the memeory consumed ? > > > > Maybe we double it to 8192 for starters? In that context, did you see my > > other message to this bug about the maximum filesize? Would increasing > > the filesize make it so that less entries in the tape catalog would be > > used because we'd have fewer archive files in the first place? Maybe > > doubling the filesize AND doubling MAX_TAPECATALOG_ENTRIES would be the > > way to go? > > > > What do you reckon? ;-) > > > > > Bruno. > > > > Cheers, > > Andree > > -- > > Andree Leidenfrost > > Sydney - Australia > > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]