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
signature.asc
Description: This is a digitally signed message part
