[ANN] r44Beta1 (was: Error while committing: applied.images max file size??)

[Bart Gauquie]

Hi Chris,

I've tested the change you provided; reran the previous scenario which
generated the large file. And the result is that the bug seems fixed indeed.
The applied.images file stays a few megabytes, but does not become 2 gig.

Thanks for the bugfix!

Kind Regards,

Bart

-- 
imagination is more important than knowledge - Albert Einstein
Logic will get you from A to B. Imagination will take you everywhere -
Albert Einstein
Learn from yesterday, live for today, hope for tomorrow. The important thing
is not to stop questioning. - Albert Einstein
The true sign of intelligence is not knowledge but imagination. - Albert
Einstein
However beautiful the strategy, you should occasionally look at the results.
- Sir Winston Churchill
It's not enough that we do our best; sometimes we have to do what's
required. - Sir Winston Churchill

On Sat, Dec 26, 2009 at 10:37 PM, Chris Muller <asqueaker at gmail.com> wrote:

> Thanks for the report Bart.  On July 8th, it appears I changed the
> method MaRecoveryRecord>>#writeTo: to add a call to setToEnd, and this
> would appear to be the cause of this file-growth problem.
>
> The reason for the change was that a warm-backup could request an
> earlier commit-log record in the current active commits.log file,
> which would cause a reposition of the file-pointer.  I therefore made
> it the responsibility of the process doing the writing to position to
> its desired position just before writing, rather than assuming it
> would be in the correct position (eof).
>
> What I failed to remember at the time is that method is generic, being
> also used for the before-images file (applied.images), which expects
> to be writing always from the *beginning* of the file, not the end.
> So my fix was put in at too low a level and inadvertently introduced
> this new bad bug, sorry.
>
> I've moved the fix to the proper place and released it as r44Beta1 on
> the "MagmaTester" project of squeaksource.  I'm quite certain this
> will fix the problem for you.  Would you please let me know if you
> encounter any further problems?
>
>  - Chris
>
> PS - Shut down the db, you can then delete your old applied.images.
>
>
> On Fri, Dec 25, 2009 at 8:40 AM, Bart Gauquie <bart.gauquie at gmail.com>
> wrote:
> > Dear all,
> >
> > I'm getting following error trying to add a new entry to a Magma
> Database:
> > aString: 'File write failed'
> > see attachment for more details.
> > The error is that the 'applied.images' file has reached 2 Gigabyte on my
> > machine.  All the commits I've done, happened in the same session ...
> > Stopping and starting database does not work, because Magma again tries
> to
> > write to the applied.images file. Restarting the image does work, since
> the
> > applied.images file is empty again.
> > Is this a known issue ? Should Magma not 'rotate' the file if it reaches
> the
> > maximum ? I'm using Ubuntu Linux 9.10 64 bit; with ext4 as a filesystem.
> > Thanks for any help,
> > Kind Regards,
> > Bart
> > --
> > imagination is more important than knowledge - Albert Einstein
> > Logic will get you from A to B. Imagination will take you everywhere -
> > Albert Einstein
> > Learn from yesterday, live for today, hope for tomorrow. The important
> thing
> > is not to stop questioning. - Albert Einstein
> > The true sign of intelligence is not knowledge but imagination. - Albert
> > Einstein
> > Gravitation is not responsible for people falling in love. - Albert
> Einstein
> >
> > _______________________________________________
> > Magma mailing list
> > Magma at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/mailman/listinfo/magma
> >
>  >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/magma/attachments/20091228/5b2039d1/attachment.htm