On 07/23/2001 02:30 PM, Vladimir V. Saveliev wrote:
> Hi
>
> Manuel Krause wrote:
>
>>
>> -->
>> The only problem may be: I was able to reproduce this memory loss once
>> again with the patch applied... (keeps the same after some reboots).
>
>
> Well, this means that there is still a problem somewhere.
At the moment I'm not able to reproduce it any more though I didn't
change my system/fs/vmware/X/... setup (only backupped/restored... the
partition).
In normal circumstances I should apologize for making that noise and be
happy now as the patch seems to work well. But you may understand - I'm
confused - not beeing able to cause the same trouble again with the same
actions :-(
I want to correct my Log [1] as I didn't get all important? related
lines (first/last).
>
>>
>> Log [1] (from /var/log/messages, look below) shows what happened when
>> vmware tried to create it's ram file after the first crash (maybe same
>> filename+location). vmware afterwards created something else occupying
>> another 128MB.
>> <--
>>
>> > Note, that this patch does not help to get back disk space which was
>> > lost earlier. Only backup-ing/restoring or --rebuild-tree can do that.
>> >
>> > Thanks,
>> > vs
>> >
>>
>> Yes, I know that fact, just hoped this space loss doesn't occur from
>> now on...
>>
>> Additional info:
>> As I was doing a backup session this weekend I got the following lines
>> in my /var/log/messages when copying this partition (from the old to a
>> newly mkreiserfsed partition):
>>
>> ....mounting: ...
>> Jul 22 17:08:12 firehead kernel: reiserfs: checking transaction log
>> (device 03:07) ...
>> Jul 22 17:08:12 firehead kernel: Using r5 hash to sort names
>> Jul 22 17:08:12 firehead kernel: Removing [25552 93425 0x0 SD]..<4>done
>> Jul 22 17:08:12 firehead kernel: Removing [25552 5872 0x0 SD]..<4>done
>> Jul 22 17:08:12 firehead kernel: There were 2 uncompleted
>> unlinks/truncates. Completed
>> .... :going on copying...
>>
>>
>> Many thanks in advance,
>>
>> Manuel
>> < reiserfs always mounted -o notail >
>>
>>
>>
>> Log [1]:
Jul 22 15:03:50 firehead kernel: vs-2100: add_save_link:search_by_key
returned 1
Jul 22 15:04:39 firehead kernel: vs-15010: reiserfs_release_objectid:
tried to free free object id (37281)<4>vs-15010:...
...in fact it repeats the last one "without end" until...
Jul 22 15:15:53 firehead kernel: vs-15010: reiserfs_release_objectid:
tried to free free object id (37281)<4>vs-2100:
add_save_link:search_by_key returned 1
Jul 22 15:15:53 firehead kernel: vs-5380: reiserfs_delete_solid_item:
[-1 37281 0x1 IND] not found
Jul 22 15:16:27 firehead kernel: vs-15010: reiserfs_release_objectid:
tried to free free object id (102785)<4>vs-15010:
reiserfs_release_objectid: tried to free free object id (102785)
...
>>
>> ((( After the next crash with newly patched kernel it shows this
>> error+quantity again after rebbot and restarting vmware after the
>> crash, but of course, another object id (25560) ;-) )))
>
>
> Do you think that if I will turn power off when vmware is working then I
> should be able to replicate your problem?
>
> Thanks,
> vs
>
I even tested this poweroff, too, after not beeing able to get this
X/vmware to crash again. This ram file doesn't stay on disk any more.
I only keep getting these log lines when running a new vmware session
after a poweroff+restart. So you may only be able to reproduce this
behaviour.
Mmh.
Thanks for your help,
Manuel
