Login | Register
My pages Projects Community openCollabNet

Discussions > users > FSVS recovery giving me "Out of memory"

fsvs
Discussion topic

Hide all messages in topic

All messages in topic

Re: FSVS recovery giving me "Out of memory"

Author pmarek
Full name P.Marek
Date 2009-06-04 09:42:01 PDT
Message
Attachments

Re: FSVS recovery giving me "Out of memory"

Author omarc
Full name Omar Carvajal
Date 2009-06-04 09:27:10 PDT
Message Philipp,

You the man, patch worked beautifully. Restore finished in 82 minutes
with 56 GB of data restored.

I am assuming then that the correct way to restore data is with the
checkout command as I was doing? I want to be able to restore the data
and then start making backups from the new server (so I assume doing a
checkout will update the WAA area?).

Thanks again for your fast help in resolving this issue.

Omar


On Jun 4, 2009, at 9:58 AM, Philipp Marek wrote:

> Hello Omar!
>
>> Using the commands you described below, everything worked out ok
>> without using trunk (I kept the same versions of FSVS and SVN).
> Fine.
>
>> I just noticed it took a lot longer to use this method than using
>> checkout. For example, it took approx. 20 minutes to recover 16 GB of
>> data with the checkout command (before it would give the out of
>> memory
>> error) vs it taking roughly 5 hours to recover 16 GB of data using
>> the
>> update command.
> Yes, I know. That's because the "update" command goes through all
> URLs to see changes,
> and then fetches them one by one ... which is bad for high-latency
> links.
>
> Checkout just does a single call, and the rest is streaming data.
>
>> Which brings me to the question of: Supposing my production server
>> crashed completely and I needed to restore the system from
>> scratch....
>> What is the correct way to recover data?
> Apply the patch I sent you and be finished with "checkout" in 20
> minutes :-)
>
>
> Regards,
>
> Phil
>
> --
> Versioning your /etc, /home or even your whole installation?
> Try fsvs (fsvs.tigris.org)!
>

Re: FSVS recovery giving me "Out of memory"

Author pmarek
Full name P.Marek
Date 2009-06-04 06:58:25 PDT
Message Hello Omar!

> Using the commands you described below, everything worked out ok
> without using trunk (I kept the same versions of FSVS and SVN).
Fine.

> I just noticed it took a lot longer to use this method than using
> checkout. For example, it took approx. 20 minutes to recover 16 GB of
> data with the checkout command (before it would give the out of memory
> error) vs it taking roughly 5 hours to recover 16 GB of data using the
> update command.
Yes, I know. That's because the "update" command goes through all URLs to see changes,
and then fetches them one by one ... which is bad for high-latency links.

Checkout just does a single call, and the rest is streaming data.

> Which brings me to the question of: Supposing my production server
> crashed completely and I needed to restore the system from scratch....
> What is the correct way to recover data?
Apply the patch I sent you and be finished with "checkout" in 20 minutes :-)


Regards,

Phil

--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: FSVS recovery giving me "Out of memory"

Author omarc
Full name Omar Carvajal
Date 2009-06-04 06:04:01 PDT
Message Philipp,

Using the commands you described below, everything worked out ok
without using trunk (I kept the same versions of FSVS and SVN).

I just noticed it took a lot longer to use this method than using
checkout. For example, it took approx. 20 minutes to recover 16 GB of
data with the checkout command (before it would give the out of memory
error) vs it taking roughly 5 hours to recover 16 GB of data using the
update command.

Which brings me to the question of: Supposing my production server
crashed completely and I needed to restore the system from scratch....
What is the correct way to recover data?

Regards,

Omar

On Jun 3, 2009, at 3:50 AM, Philipp Marek wrote:

> Hello Omar!
>
>
> Could you please try
> fsvs urls file:///home/disk02/​repository/trunk/u
> fsvs update
> and tell me whether that works?
>
>
> Regards,
>
> Phil
>
> --
> Versioning your /etc, /home or even your whole installation?
> Try fsvs (fsvs.tigris.org)!
>

Re: FSVS recovery giving me "Out of memory"

Author pmarek
Full name P.Marek
Date 2009-06-03 23:14:44 PDT
Message Hello Omar!

How's that?


Index: update.c
====================​====================​====================​=======
--- update.c (Revision 2261)
+++ update.c (Arbeitskopie)
@@ -984,7 +984,7 @@
                        /* This may be NULL if we got only property-changes, no file
                         * data changes. */
                        if (sts->filehandle_pool)
- apr_pool_clear(sts-​>filehandle_pool);​
+ apr_pool_destroy(sts​->filehandle_pool​);
                        sts->filehandle_pool=NULL;
                        /* Now the filehandles should be closed. */
                        /* This close() before rename() is necessary to find out


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: FSVS recovery giving me "Out of memory"

Author pmarek
Full name P.Marek
Date 2009-06-03 00:50:21 PDT
Message Hello Omar!


Could you please try
    fsvs urls file:///home/disk02/​repository/trunk/u
    fsvs update
and tell me whether that works?


Regards,

Phil

--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: FSVS recovery giving me "Out of memory"

Author pmarek
Full name P.Marek
Date 2009-06-02 23:43:34 PDT
Message Hello Omar!


> Here is the information you asked for:
>
> Top:
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 7544 root 20 0 4607m 2.7g 1928 T 16 74.6 14:18.54 fsvs
This qualifies as memory leak, I think.

> strace:
...
> 17:05:32.658997 mmap(NULL, 143360, PROT_READ|PROT_WRITE, MAP_PRIVATE|
> MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
> 17:05:32.729173 brk(0x3d811000) = 0x3d7ef000
Well, no more memory.


> FSVS version is 1.1.17, Subversion is 1.6.2.
Hmmm, that current versions? Debian only has 1.6.2, but I'll try to reproduce.

> Let me know if you need any other information.
Well, if you have the time, can you reproduce that with trunk too?

> Thanks for your quick response!
You're welcome!


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: FSVS recovery giving me "Out of memory"

Author omarc
Full name Omar Carvajal
Date 2009-06-02 15:03:18 PDT
Message Philipp,

Here is the information you asked for:

Top:

top - 17:05:32 up 8:37, 5 users, load average: 1.64, 1.66, 1.57
Tasks: 1 total, 0 running, 0 sleeping, 1 stopped, 0 zombie
Cpu(s): 20.9%us, 9.5%sy, 0.0%ni, 61.5%id, 8.1%wa, 0.0%hi,
0.0%si, 0.0%st
Mem: 3794324k total, 3772708k used, 21616k free, 23992k buffers
Swap: 2104472k total, 952496k used, 1151976k free, 717268k cached

   PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  7544 root 20 0 4607m 2.7g 1928 T 16 74.6 14:18.54 fsvs


top - 17:05:33 up 8:37, 5 users, load average: 1.64, 1.66, 1.57
Tasks: 0 total, 0 running, 0 sleeping, 0 stopped, 0 zombie
Cpu(s): 5.4%us, 9.2%sy, 0.0%ni, 60.3%id, 25.1%wa, 0.0%hi,
0.0%si, 0.0%st
Mem: 3794324k total, 931324k used, 2863000k free, 24096k buffers
Swap: 2104472k total, 54604k used, 2049868k free, 721268k cached

   PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND


strace:

17:05:32.636030 write(1, "17:05:32.636 cs___update_manber["..., 78) = 78
17:05:32.636126 read(7, "\303]7=D\325\202+E\332\260%N
\241i3\320\203\2​33c\377ki\32z\26~​\274d\0\367L"...,​ 4096) = 4096
17:05:32.636215 read(7, "\333\331}W\35sC\3\251\371d
\365\16\3070\366​\270\17:\322\242​\350qh'l\25\244U​301\36;"..., 4096) =
4096
17:05:32.636362 read(7, "MU\334q*\271\232​\337J/\27'\263\3​0\351Q\260
\1\vl\261\t\371​J\355\36qJ\301\3​05\213"..., 4096) = 4096
17:05:32.636456 read(7, "\24t.\241\212\3​01:\323\17}K\227​257kLK
\313\274\356\235​\313L\325\344\35​0z\16{x*\320\26".​.., 4096) = 4096
17:05:32.641653 write(6, "03084 NHHILLSBOROUGH "...,
102400) = 102400
17:05:32.642166 stat("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=3519, ...}) = 0
17:05:32.642313 write(1, "17:05:32.642 cs___update_manber["..., 78) = 78
17:05:32.646103 stat("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=3519, ...}) = 0
17:05:32.646250 write(1, "17:05:32.646 cs___end_of_block[c"..., 96) = 96
17:05:32.646335 stat("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=3519, ...}) = 0
17:05:32.646456 write(1, "17:05:32.646 cs___update_manber["..., 78) = 78
17:05:32.646548 read(7, "\275!9s\377/(\253=\342\341j
\216\242\26\226​272\362\375\303s​\16$\353\252*\3​60\374b
\344\332\322"..., 4096) = 4096
17:05:32.646639 read(7, ":\342Fm\207\275​24bP\343\247\35​271K
\376\215\31\251U​\374\244\307G{\3​41\234U\246j~:\32​"..., 4096) = 4096
17:05:32.646723 read(7, "s\21\302G\\\22​1so\265\311Q\235​211+
\262\273\2732\32​1\213V\254r\0\32​0\374\fX2\0(\331​"..., 4096) = 4096
17:05:32.646806 read(7, "\315\264\241\23​0`\300e\313\2345.​?\21\"!
\310\22\372\235​v\310cE\355Bpq\2​76Od\262\233"..., 4096) = 4096
17:05:32.652193 write(6, "22558 VAWESTMORELAND "...,
102400) = 102400
17:05:32.652686 stat("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=3519, ...}) = 0
17:05:32.652822 write(1, "17:05:32.653 cs___update_manber["..., 78) = 78
17:05:32.656984 stat("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=3519, ...}) = 0
17:05:32.657161 write(1, "17:05:32.657 cs___end_of_block[c"..., 96) = 96
17:05:32.657250 stat("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=3519, ...}) = 0
17:05:32.657369 write(1, "17:05:32.657 cs___update_manber["..., 78) = 78
17:05:32.657470 read(7, "dx\333\335\376g​>\205\321\334\​333d
\317\246\371\211​\5\7\302\271\37​&\f\232kj(lI+​245y"..., 4096) = 4096
17:05:32.657570 read(7, "\30xz\304\4~p\30<\374\t
\3645]\262\217\2​0\23\325Y\352'n\​17\337\205i\206le​h\10"..., 4096) = 4096
17:05:32.657786 read(7, "\360\303\217\23​1u3\335B\277n&​\257\264\217\220​?
$\32\336\5\352p\34r> \16Z\313\3202^"..., 4096) = 4096
17:05:32.657885 read(7, "\7r\6\275\332\​322\n\216\202;\2​1O\324\210\247C
\2\312\330\254m​375\\\30\351\7​f\205w\267\275\3​41"..., 4096) = 4096
17:05:32.658997 mmap(NULL, 143360, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
17:05:32.729173 brk(0x3d811000) = 0x3d7ef000
17:05:32.729253 mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
17:05:32.729329 mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|
MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory)
17:05:32.729398 mmap(NULL, 67108864, PROT_NONE, MAP_PRIVATE|
MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory)
17:05:32.729463 mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|
MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory)
17:05:32.729526 mmap(NULL, 67108864, PROT_NONE, MAP_PRIVATE|
MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory)
17:05:32.822693 write(1, "Out of memory - terminating appl"..., 41) = 41
17:05:32.822829 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
17:05:32.822927 tgkill(7544, 7544, SIGABRT) = 0
17:05:32.823075 --- SIGABRT (Aborted) @ 0 (0) ---
Process 7544 detached


FSVS version is 1.1.17, Subversion is 1.6.2.

Let me know if you need any other information.

Thanks for your quick response!

Omar


On Jun 2, 2009, at 3:37 AM, Philipp Marek wrote:

> Hello Omar!
>
>> I am trying to recover data from a backup I made to an external
>> hard drive using FSVS.
>>
>> I am issuing the command "fsvs checkout -d . file:///home/disk02/​repository/trunk/u
>> " and
>> I get the following message:
> ...
>> 17:01:00.257 cs___update_manber[c​hecksum.c:684] block continues
>> after 1433600.
>> Out of memory - terminating application.
>>
>> I am doing this on an openSuse 11.1 linux box with a 64 bit
>> processor, 4 gb of ram.
>>
>> What could I be doing wrong?
> I don't think that you are doing anything wrong. The machine is
> certainly big enough
> this usage.
>
> Could you please run that command, and while it's running go to
> another console and run
> top -b -d 1 -p `pidof fsvs`
> to get some information about the memory usage?
>
> If you've got a third shell, you might also do
> strace -tt -p <pid of fsvs>
> and send me the last few lines.
>
> What version of FSVS and subversion are you using?
>
>
> If it's a problem needing a fast solution, you could try to checkout
> the various
> directories - so eg. "bin", "etc", "sbin", "usr" etc. instead of
> "/"; the clean up the
> wrong working copies, and do a "sync-repos" ... but I wouldn't
> advise that, it's too
> much work. And your checkout should simply work!
>
> It's possible that this is an easy bug, and you might get a patch
> soon ...
>
>
> Regards,
>
> Phil
>
> --
> Versioning your /etc, /home or even your whole installation?
> Try fsvs (fsvs.tigris.org)!
>

Re: FSVS recovery giving me "Out of memory"

Author pmarek
Full name P.Marek
Date 2009-06-02 00:37:54 PDT
Message Hello Omar!

> I am trying to recover data from a backup I made to an external hard drive using FSVS.
>
> I am issuing the command "fsvs checkout -d . file:///home/disk02/​repository/trunk/u" and
> I get the following message:
...
> 17:01:00.257 cs___update_manber[c​hecksum.c:684] block continues after 1433600.
> Out of memory - terminating application.
>
> I am doing this on an openSuse 11.1 linux box with a 64 bit processor, 4 gb of ram.
>
> What could I be doing wrong?
I don't think that you are doing anything wrong. The machine is certainly big enough
this usage.

Could you please run that command, and while it's running go to another console and run
  top -b -d 1 -p `pidof fsvs`
to get some information about the memory usage?

If you've got a third shell, you might also do
  strace -tt -p <pid of fsvs>
and send me the last few lines.

What version of FSVS and subversion are you using?


If it's a problem needing a fast solution, you could try to checkout the various
directories - so eg. "bin", "etc", "sbin", "usr" etc. instead of "/"; the clean up the
wrong working copies, and do a "sync-repos" ... but I wouldn't advise that, it's too
much work. And your checkout should simply work!

It's possible that this is an easy bug, and you might get a patch soon ...


Regards,

Phil

--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

FSVS recovery giving me "Out of memory"

Author omarc
Full name Omar Carvajal
Date 2009-06-01 14:51:27 PDT
Message Hi All,

I am trying to recover data from a backup I made to an external hard drive using FSVS.

I am issuing the command "fsvs checkout -d . file:///home/disk02/​repository/trunk/u" and I get the following message:

...... 3932371 ./s/dsm/versions/emp​28118wc/ebc/help/dsm​latam.hlp
17:01:00.157 ops__find_entry_byna​me[est_ops.c:762] Searching for dsms.hlp (dsms.hlp) found no entry (ignored_too=0)
17:01:00.157 cb__add_entry[racallback.c:163] entry s/dsm/versions/emp28​118wc/ebc/help/dsms.​hlp, mode 0100000; not found, may create
17:01:00.157 ops__allocate[est_ops.c:831] need 1 blocks, freelist=0x3d5fe5f0
17:01:00.157 ops__allocate[est_ops.c:860] splitting block; 12 remain
17:01:00.157 ops__allocate[est_ops.c:886] giving 1 blocks at 0x3d5fefb0
17:01:00.157 up__parse_prop[update.c:165] got property for dsms.hlp: svn:entry:committed-rev=2
17:01:00.157 up__parse_prop[update.c:165] got property for dsms.hlp: svn:entry:committed-​date=2009-04-19T13:0​6:54.876587Z
17:01:00.157 up__parse_prop[update.c:165] got property for dsms.hlp: svn:entry:last-author=root
17:01:00.157 up__parse_prop[update.c:165] got property for dsms.hlp: svn:entry:uuid=e6b93​b68-2a8e-11de-bc85-4​b2b9581cfd7
17:01:00.157 up__parse_prop[update.c:165] got property for dsms.hlp: svn:text-time=2007-0​2-10T19:58:16.000000​Z
17:01:00.157 up__parse_prop[update.c:262] marking mtime "2007-02-10T19:58:16.000000Z" to Sat Feb 10 14:58:16 2007
17:01:00.157 up__parse_prop[update.c:165] got property for dsms.hlp: svn:unix-mode=0660
17:01:00.157 up__parse_prop[update.c:283] marking mode "0660" to 0660
17:01:00.157 up__parse_prop[update.c:165] got property for dsms.hlp: svn:owner=1002 mike
17:01:00.157 cch__hash_find[cache.c:258] looking for 2AD2D = mike
17:01:00.157 up__parse_prop[update.c:199] marking owner 1002 mike to 1002
17:01:00.157 up__parse_prop[update.c:165] got property for dsms.hlp: svn:group=1001 ccigrp
17:01:00.157 cch__hash_find[cache.c:258] looking for 2123A463 = ccigrp
17:01:00.157 up__parse_prop[update.c:230] marking group 1001 ccigrp to 1001
17:01:00.157 up__apply_textdelta[​update.c:835] target is ./s/dsm/versions/emp​28118wc/ebc/help/dsm​s.hlp (0100600),
17:01:00.157 up__apply_textdelta[​update.c:836] temp is ./s/dsm/versions/emp​28118wc/ebc/help/dsm​s.hlp.up.tmp
17:01:00.157 cs___end_of_block[ch​ecksum.c:537] manber reinit
17:01:00.157 cs___end_of_block[ch​ecksum.c:634] on return at fpos=0: 00000000 (databits= 0)
17:01:00.158 ops__build_path[est_ops.c:658] 0x3d5fefb0 found in cache index 44; lru 44
17:01:00.158 cs__new_manber_filte​r[checksum.c:841] initiating MD5 streaming for ./s/dsm/versions/emp​28118wc/ebc/help/dsm​s.hlp
17:01:00.182 cs___update_manber[c​hecksum.c:671] got a block with 102400 bytes
17:01:00.184 cs___end_of_block[ch​ecksum.c:634] on return at fpos=102400: B293435F (databits=ff)
17:01:00.184 cs___update_manber[c​hecksum.c:684] block continues after 102400.
17:01:00.187 cs___update_manber[c​hecksum.c:671] got a block with 102400 bytes
17:01:00.188 cs___end_of_block[ch​ecksum.c:618] manber found a border: 54166 32ADE73D 8DA20000 06cf0acca7569b85a84e​b6c1d340c9c7
17:01:00.188 cs___end_of_block[ch​ecksum.c:634] on return at fpos=156566: 8DA20000 (databits=ff)
17:01:00.188 cs___update_manber[c​hecksum.c:693] block ends after 156566; size 156566 bytes (border=54166).
17:01:00.188 ops__build_path[est_ops.c:658] 0x3d5fefb0 found in cache index 44; lru 44
17:01:00.188 waa__get_waa_directo​ry[waa.c:422] path is ./s/dsm/versions/emp​28118wc/ebc/help/dsm​s.hlp
17:01:00.188 Increment[helper.c:465] adding /u
17:01:00.188 Increment[helper.c:465] adding /
17:01:00.188 Increment[helper.c:465] adding ./s/dsm/versions/emp​28118wc/ebc/help/dsm​s.hlp
17:01:00.188 hlp__pathcopy[helper.c:560] finished path is /u/s/dsm/versions/em​p28118wc/ebc/help/ds​ms.hlp
17:01:00.188 waa__get_waa_directo​ry[waa.c:461] md5 of /u/s/dsm/versions/em​p28118wc/ebc/help/ds​ms.hlp
17:01:00.188 waa__get_waa_directo​ry[waa.c:506] returning /home/disk02/fsvs/wa​a/f3/1b/b3258e3595c1​76bc464cb41a7e6e/
17:01:00.188 waa__open[waa.c:596] tmp for target /home/disk02/fsvs/wa​a/f3/1b/b3258e3595c1​76bc464cb41a7e6e/md5​s is /home/disk02/fsvs/wa​a/f3_1b_b3258e3595c1​76bc464cb41a7e6e_md5​s.tmp
17:01:00.188 waa__open[waa.c:616] got fh 7
17:01:00.188 cs___update_manber[c​hecksum.c:711] now doing manber-hashing for ./s/dsm/versions/emp​28118wc/ebc/help/dsm​s.hlp...
17:01:00.188 cs___end_of_block[ch​ecksum.c:537] manber reinit
17:01:00.188 cs___end_of_block[ch​ecksum.c:634] on return at fpos=156566: 00000000 (databits= 0)
17:01:00.189 cs___end_of_block[ch​ecksum.c:618] manber found a border: 25383 42973190 44720000 1cd60d4dcd5ca62a5035​73c5f13b23ab
17:01:00.189 cs___end_of_block[ch​ecksum.c:634] on return at fpos=181949: 44720000 (databits=ff)
17:01:00.189 cs___update_manber[c​hecksum.c:693] block ends after 181949; size 25383 bytes (border=25383).
17:01:00.189 cs___end_of_block[ch​ecksum.c:537] manber reinit
17:01:00.189 cs___end_of_block[ch​ecksum.c:634] on return at fpos=181949: 00000000 (databits= 0)
17:01:00.189 cs___end_of_block[ch​ecksum.c:618] manber found a border: 5341 95F418C4 878C0000 42d4f7c4f4fcbd30457b​d91d9fc6f2fc
17:01:00.189 cs___end_of_block[ch​ecksum.c:634] on return at fpos=187290: 878C0000 (databits=ff)
17:01:00.189 cs___update_manber[c​hecksum.c:693] block ends after 187290; size 5341 bytes (border=5341).
17:01:00.189 cs___end_of_block[ch​ecksum.c:537] manber reinit
17:01:00.189 cs___end_of_block[ch​ecksum.c:634] on return at fpos=187290: 00000000 (databits= 0)
17:01:00.189 cs___end_of_block[ch​ecksum.c:634] on return at fpos=204800: 2B38F90F (databits=ff)
17:01:00.189 cs___update_manber[c​hecksum.c:684] block continues after 204800.
17:01:00.193 cs___update_manber[c​hecksum.c:671] got a block with 102400 bytes
17:01:00.194 cs___end_of_block[ch​ecksum.c:634] on return at fpos=307200: 4F9A986B (databits=ff)
17:01:00.194 cs___update_manber[c​hecksum.c:684] block continues after 307200.
17:01:00.198 cs___update_manber[c​hecksum.c:671] got a block with 102400 bytes
17:01:00.199 cs___end_of_block[ch​ecksum.c:618] manber found a border: 57931 C520A529 99D80000 cf1c04f6d0914c64ab26​970db9c1a02e
17:01:00.199 cs___end_of_block[ch​ecksum.c:634] on return at fpos=365131: 99D80000 (databits=ff)
17:01:00.199 cs___update_manber[c​hecksum.c:693] block ends after 365131; size 177841 bytes (border=57931).
17:01:00.199 cs___end_of_block[ch​ecksum.c:537] manber reinit
17:01:00.199 cs___end_of_block[ch​ecksum.c:634] on return at fpos=365131: 00000000 (databits= 0)
17:01:00.200 cs___end_of_block[ch​ecksum.c:634] on return at fpos=409600: 6F925330 (databits=ff)
17:01:00.200 cs___update_manber[c​hecksum.c:684] block continues after 409600.
17:01:00.203 cs___update_manber[c​hecksum.c:671] got a block with 102400 bytes
17:01:00.214 cs___end_of_block[ch​ecksum.c:634] on return at fpos=512000: 7EEC976C (databits=ff)
17:01:00.214 cs___update_manber[c​hecksum.c:684] block continues after 512000.
17:01:00.219 cs___update_manber[c​hecksum.c:671] got a block with 102400 bytes
17:01:00.219 cs___end_of_block[ch​ecksum.c:618] manber found a border: 67829 F3A2DEFA B4DC0000 84896878f5b508ed53f5​de1f89a19ef3
17:01:00.220 cs___end_of_block[ch​ecksum.c:634] on return at fpos=579829: B4DC0000 (databits=ff)
17:01:00.220 cs___update_manber[c​hecksum.c:693] block ends after 579829; size 214698 bytes (border=67829).
17:01:00.220 cs___end_of_block[ch​ecksum.c:537] manber reinit
17:01:00.220 cs___end_of_block[ch​ecksum.c:634] on return at fpos=579829: 00000000 (databits= 0)
17:01:00.220 cs___end_of_block[ch​ecksum.c:634] on return at fpos=614400: D5B2F210 (databits=ff)
17:01:00.220 cs___update_manber[c​hecksum.c:684] block continues after 614400.
17:01:00.224 cs___update_manber[c​hecksum.c:671] got a block with 102400 bytes
17:01:00.225 cs___end_of_block[ch​ecksum.c:618] manber found a border: 59909 C1180007 DAC60000 8ff75ec1f78f262fe711​e516e9c4a598
17:01:00.225 cs___end_of_block[ch​ecksum.c:634] on return at fpos=674309: DAC60000 (databits=ff)
17:01:00.225 cs___update_manber[c​hecksum.c:693] block ends after 674309; size 94480 bytes (border=59909).
17:01:00.225 cs___end_of_block[ch​ecksum.c:537] manber reinit
17:01:00.225 cs___end_of_block[ch​ecksum.c:634] on return at fpos=674309: 00000000 (databits= 0)
17:01:00.226 cs___end_of_block[ch​ecksum.c:634] on return at fpos=716800: FD682880 (databits=ff)
17:01:00.226 cs___update_manber[c​hecksum.c:684] block continues after 716800.
17:01:00.229 cs___update_manber[c​hecksum.c:671] got a block with 102400 bytes
17:01:00.230 cs___end_of_block[ch​ecksum.c:618] manber found a border: 62843 88BBD6B5 D18E0000 2f61d8ab610c096d5c49​88c40bafbc53
17:01:00.230 cs___end_of_block[ch​ecksum.c:634] on return at fpos=779643: D18E0000 (databits=ff)
17:01:00.230 cs___update_manber[c​hecksum.c:693] block ends after 779643; size 105334 bytes (border=62843).
17:01:00.230 cs___end_of_block[ch​ecksum.c:537] manber reinit
17:01:00.230 cs___end_of_block[ch​ecksum.c:634] on return at fpos=779643: 00000000 (databits= 0)
17:01:00.231 cs___end_of_block[ch​ecksum.c:634] on return at fpos=819200: CA2B4AD1 (databits=ff)
17:01:00.231 cs___update_manber[c​hecksum.c:684] block continues after 819200.
17:01:00.235 cs___update_manber[c​hecksum.c:671] got a block with 102400 bytes
17:01:00.236 cs___end_of_block[ch​ecksum.c:618] manber found a border: 100979 98D9FFFD 7C3A0000 42706d9bb3c604dce7d5​d91c12707de2
17:01:00.237 cs___end_of_block[ch​ecksum.c:634] on return at fpos=920179: 7C3A0000 (databits=ff)
17:01:00.237 cs___update_manber[c​hecksum.c:693] block ends after 920179; size 140536 bytes (border=100979).
17:01:00.237 cs___end_of_block[ch​ecksum.c:537] manber reinit
17:01:00.237 cs___end_of_block[ch​ecksum.c:634] on return at fpos=920179: 00000000 (databits= 0)
17:01:00.237 cs___end_of_block[ch​ecksum.c:634] on return at fpos=921600: 88A1186F (databits=ff)
17:01:00.237 cs___update_manber[c​hecksum.c:684] block continues after 921600.
17:01:00.240 cs___update_manber[c​hecksum.c:671] got a block with 102400 bytes
17:01:00.241 cs___end_of_block[ch​ecksum.c:618] manber found a border: 82356 4560BDF0 32FC0000 0941c18f45d7cf7ed1f4​83f33eebb951
17:01:00.241 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1003956: 32FC0000 (databits=ff)
17:01:00.241 cs___update_manber[c​hecksum.c:693] block ends after 1003956; size 83777 bytes (border=82356).
17:01:00.241 cs___end_of_block[ch​ecksum.c:537] manber reinit
17:01:00.241 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1003956: 00000000 (databits= 0)
17:01:00.242 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1024000: 12D6382D (databits=ff)
17:01:00.242 cs___update_manber[c​hecksum.c:684] block continues after 1024000.
17:01:00.245 cs___update_manber[c​hecksum.c:671] got a block with 102400 bytes
17:01:00.246 cs___end_of_block[ch​ecksum.c:618] manber found a border: 60166 F87B4A50 C9520000 39012265135c9a3dc69f​972a0a7b5350
17:01:00.246 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1084166: C9520000 (databits=ff)
17:01:00.246 cs___update_manber[c​hecksum.c:693] block ends after 1084166; size 80210 bytes (border=60166).
17:01:00.246 cs___end_of_block[ch​ecksum.c:537] manber reinit
17:01:00.246 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1084166: 00000000 (databits= 0)
17:01:00.247 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1126400: 163EBB8A (databits=ff)
17:01:00.247 cs___update_manber[c​hecksum.c:684] block continues after 1126400.
17:01:00.250 cs___update_manber[c​hecksum.c:671] got a block with 102400 bytes
17:01:00.251 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1228800: 6D623A88 (databits=ff)
17:01:00.251 cs___update_manber[c​hecksum.c:684] block continues after 1228800.
17:01:00.253 cs___update_manber[c​hecksum.c:671] got a block with 102400 bytes
17:01:00.253 cs___end_of_block[ch​ecksum.c:618] manber found a border: 38402 F6AE94A2 DF240000 1d1baa7bd26aae5b6b66​78fb247eca81
17:01:00.253 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1267202: DF240000 (databits=ff)
17:01:00.253 cs___update_manber[c​hecksum.c:693] block ends after 1267202; size 183036 bytes (border=38402).
17:01:00.253 cs___end_of_block[ch​ecksum.c:537] manber reinit
17:01:00.253 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1267202: 00000000 (databits= 0)
17:01:00.254 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1331200: 2ECCB391 (databits=ff)
17:01:00.254 cs___update_manber[c​hecksum.c:684] block continues after 1331200.
17:01:00.256 cs___update_manber[c​hecksum.c:671] got a block with 102400 bytes
17:01:00.256 cs___end_of_block[ch​ecksum.c:618] manber found a border: 5327 B80A6319 12D20000 269e3e78cc64a441a7eb​eeabd3ca05c2
17:01:00.256 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1336527: 12D20000 (databits=ff)
17:01:00.256 cs___update_manber[c​hecksum.c:693] block ends after 1336527; size 69325 bytes (border=5327).
17:01:00.256 cs___end_of_block[ch​ecksum.c:537] manber reinit
17:01:00.256 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1336527: 00000000 (databits= 0)
17:01:00.256 cs___end_of_block[ch​ecksum.c:618] manber found a border: 29917 A0D739D3 43A00000 5ffd7026363e4f8c5ffe​ed93a31532f6
17:01:00.256 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1366444: 43A00000 (databits=ff)
17:01:00.256 cs___update_manber[c​hecksum.c:693] block ends after 1366444; size 29917 bytes (border=29917).
17:01:00.256 cs___end_of_block[ch​ecksum.c:537] manber reinit
17:01:00.256 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1366444: 00000000 (databits= 0)
17:01:00.257 cs___end_of_block[ch​ecksum.c:618] manber found a border: 25005 629B5AD3 30EA0000 8a8c5c87c87997094397​5f12901ab0e1
17:01:00.257 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1391449: 30EA0000 (databits=ff)
17:01:00.257 cs___update_manber[c​hecksum.c:693] block ends after 1391449; size 25005 bytes (border=25005).
17:01:00.257 cs___end_of_block[ch​ecksum.c:537] manber reinit
17:01:00.257 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1391449: 00000000 (databits= 0)
17:01:00.257 cs___end_of_block[ch​ecksum.c:618] manber found a border: 19995 D492D6B5 746C0000 4d07a456271829de2b5e​ef8f2a7f79e8
17:01:00.257 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1411444: 746C0000 (databits=ff)
17:01:00.257 cs___update_manber[c​hecksum.c:693] block ends after 1411444; size 19995 bytes (border=19995).
17:01:00.257 cs___end_of_block[ch​ecksum.c:537] manber reinit
17:01:00.257 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1411444: 00000000 (databits= 0)
17:01:00.257 cs___end_of_block[ch​ecksum.c:634] on return at fpos=1433600: 5F9C56A8 (databits=ff)
17:01:00.257 cs___update_manber[c​hecksum.c:684] block continues after 1433600.
Out of memory - terminating application.


I am doing this on an openSuse 11.1 linux box with a 64 bit processor, 4 gb of ram.

What could I be doing wrong?

Thanks in advance,

Omar
Messages per page: