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]
