<div dir="ltr">Good idea. The patch looks sane just looking at the diff, but I'd like to look at it in context more first.<br><br>Would you mind uploading this to <a href="http://codereview.appspot.com">codereview.appspot.com</a>? They have a command-line tool you can run from your svn repo that does the upload.<br>
<br><div class="gmail_quote">On Tue, Jul 29, 2008 at 11:54 AM, Gavin Carr <span dir="ltr"><<a href="mailto:gavin@openfusion.com.au">gavin@openfusion.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm messing around with some pretty big backups at the moment (400-800GB<br>
trees), and I'm finding that brackup is sucking up huge gobs of RAM while<br>
doing this (like 8GB).<br>
<br>
One of the culprits seems to be the metafile data, which we accumulate<br>
over the course of the backup and then write out at the end. My metafiles<br>
are coming in at around 600MB on these backups, and the in-core footprint<br>
seems about 1GB, so that's a big chunk of ram we're holding for no very<br>
good reason.<br>
<br>
The attached patch writes the metafile incrementally instead, writing to<br>
a tempfile, and then renaming at the end (so failures don't leave partial<br>
metafiles lying around). The only wrinkle is that we still have to spool<br>
entries if we have a CompositeChunk open, because we can't record the<br>
metafile entry without the chunk checksum.<br>
<br>
Does this look sane? Please comment/test.<br>
<br>
Cheers,<br>
<font color="#888888">Gavin<br>
<br>
</font></blockquote></div><br></div>