On 16 Jun 2001 17:58:59 -0400, Jeffrey Stedfast wrote:
> Ibex files aren't the same type of index that the summary file is. The
> summary file has a chunk of data per message that contains info like
> subject, to, from, etc. The ibex files are more of a lookup table that
> indexes all the words just and which message(s) they were found in.
>
> What I suspect is happening is that when messages are deleted, the code
> does not force a re-ibexification of the messages because it'd be
> extremely slow to do on large mailboxes. Simply put, this is an
> optimization.
Jeff has it right. Think of a (fragmented) filesystem that has a lot of
files in it then you delete some - the filesystem doesn't shrink (and
more specifically the extent of used blocks doesn't really change). A
repack process that would allow the file to shrink would be extremely
slow (much faster just to remove it and rebuild totally). I think
another optimisation is that it never forgets words when they run out of
references.
I guess a reset index function is possible.
> If you are tight on space or you don't search much, then you can always
> turn the indexing off. This will make it so that .ibex files will not be
> created but, at the same time, searches will be slower if searching on
> body content.
Turning indexing off has to be done manually at the moment.
> Jeff
>
> On 16 Jun 2001 13:46:26 -0400, Michael Leone wrote:
> > On 16 Jun 2001 11:53:50 -0400, Michael Leone wrote:
> >
> > > Why would the index be close to twice as large as the file it's
> > > indexing? I deleted/expunged many mails from this folder, and the mbox
> > > size went from 3.3M down to the 2.59M you see above. Yet the .ibex file
> > > size stayed the same, at 4M. Wouldn't it have also gone down, since
> > > there was now over 100 emails less to index?
> >
> > Ok. So after deleting even more email (I'm now down to a mbox size of
> > 2M, from it's original size of 3.3M), I closed Evo, and deleted the
> > .ibex file.
> >
> > This .ibex file was 4.4M in size; it never changed size, to reflect the
> > now smaller size of the mbox.
> >
> > So, then I restarted Evo, and - as expected - it recreated the .ibex
> > file.
> >
> > [turgon@minas-aran LRP]$ ls -la
> > total 2782
> > drwxr-xr-x 2 turgon turgon 146 Jun 16 13:33 ./
> > drwxr-xr-x 41 turgon turgon 1035 Jun 10 13:26 ../
> > -rwxr-xr-x 1 turgon turgon 63 Jan 19 23:23
> > folder-metadata.xml*
> > -rw------- 1 turgon turgon 2001376 Jun 16 13:30 mbox
> > -rwxr-xr-x 1 turgon turgon 124308 Jun 16 13:33 mbox.ev-summary*
> > -rw------- 1 turgon turgon 711936 Jun 16 13:33 mbox.ibex
> >
> > Note that the size is now only 17% of it's previous size (711,936 v
> > 4,006,400). And, as a side effect, that I've gained 3M disk space. :-)
> >
> > A suggestion: perhaps a button, or menu item, to "Rebuild index". Looks
> > like (for now), the .ibex isn't being updated to reflect downward sizing
> > of mbox files (altho I will admit that this is the only folder I've
> > tried this experiment on, as of this moment). Manually rebuilding the
> > index would help to clear out the cruft (a word I've only heard used in
> > conjunction with Linux, BTW :-).
> >
> > Perhaps it wouldn't hurt, every now and again, to close Evo, and rm all
> > the .ibex files, so they could periodically be rebuilt. I'd hate to put
> > a command like that in a cron script, since Evo might be open and
> > running when the .ibex files got removed; and I presume that could cause
> > havoc.
> >
> >
> >
> >
> > _______________________________________________
> > evolution maillist - [EMAIL PROTECTED]
> > http://lists.helixcode.com/mailman/listinfo/evolution
>
>
> _______________________________________________
> evolution maillist - [EMAIL PROTECTED]
> http://lists.helixcode.com/mailman/listinfo/evolution
_______________________________________________
evolution maillist - [EMAIL PROTECTED]
http://lists.helixcode.com/mailman/listinfo/evolution
