On 07/29/2001 08:15 PM, Manuel Krause wrote:
> On 07/29/2001 07:46 PM, [EMAIL PROTECTED] wrote:
>
>> Manuel Krause wrote:
>>
>>> On 07/29/2001 06:31 PM, [EMAIL PROTECTED] wrote:
>>>
>>>> Hi
>>>>
>>>> Manuel Krause wrote:
>>>>
>>>>> On 07/29/2001 04:41 PM, Vladimir V.Saveliev wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> Manuel Krause wrote:
>>>>>>
>>>>>>>> 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...
>>>>>>>>
>>>>>>>>
>>>>>> Ok, the "unlink-truncate-rename.." patch
>>>>>>
>(ftp.namesys.com/pub/reiserfs-for-2.4/2.4.7.pending/2.4.7-unlink-truncate-rename-rmdir.dif.bz2)
>
>>>>>>
>>>>>> is updated.
>>>>>>
>>>>>> The problem was that previous version of the patch does not expect
>>>>>> truncates to unlinked files which vmware does.
>>>>>>
>>>>>> Thanks,
>>>>>> vs
>>>>>>
>>>>>>
>>>>> Hi, Vladimir!
>>>>>
>>>>> I applied the new patch, recompiled the kernel, booted, started
>>>>> vmware,
>>>>> made a complete power-off, then power-on, and df showed some 133MB
>>>>> more
>>>>> on disk (like it was when vmware was up). Rebooting didn't make a
>>>>> difference.
>>>>>
>>>>> Seems your patch doesn't like this test any more? I haven't made a
>>>>> reiserfsck --rebuild-tree yet.
>>>>>
>>>>>
>>>> Hmm, could you please look at the system logs?
>>>> Is there something like:
>>>> Jul 29 18:27:36 digger kernel: Removing [3 36 0x0 SD]..<4>done
>>>> or
>>>> Jul 29 18:27:37 digger kernel: Truncating [3 13 0x0 SD] to 72224
>>>> ..<4>done
>>>>
>>>> Thanks,
>>>> vs
>>>>
>>>>
>>> I had a look: Nothing like that to be found.
>>>
>>> Did I do something wrong? I patched the old one with ...-R and then
>>> patched the new one without any problems. Then "make dep clean bzImage
>>> bzlilo modules modules_install". And it made the kernel I'm really
>>> running. The patch I downloaded is from today and takes 5766 B.
>>>
>>> Do you have an idea?!
>>>
>>
>> The uncompleted unlinks do not get completed on mount time when
>> filesystem is mounted read-only.
>> How does that filesystem get mounted in your case?
>>
>> Thanks,
>> vs
>>
>
>
> Oh, heaven! Thanks, Vladimir!
>
> Of course, since SuSE's original setup for ext2 partitions I have a line
> "read-only" /etc/lilo.conf and in my /etc/fstab:
>
> /dev/hda7 / reiserfs defaults,noatime,notail 1 1
>
Ok, I had to insert an explicit line "read-write" for this image=... &
root=... to finally work.
But then it automatically completed all outstanding unlinks! Wow!
My /var/log/boot.msg shows these lines now:
...
<4>reiserfs: checking transaction log (device 03:07) ...
<4>Using r5 hash to sort names
<4>Removing [25349 93432 0x0 SD]..<4>done
<4>Removing [7344 25434 0x0 SD]..<4>done
<4>Removing [25349 25122 0x0 SD]..<4>done
<4>Removing [25349 6145 0x0 SD]..<4>done
<4>There were 4 uncompleted unlinks/truncates. Completed
<4>ReiserFS version 3.6.25
<4>VFS: Mounted root (reiserfs filesystem).
...
>
> I assume, both ones are causing this read-only mount?! (There was a post
> regarding the numbers to choose for reiserfs in fstab recently - IIRC?)
I was wrong, I had to read "man 5 fstab" again... ;-)
>
> So, in fact it mounts "/" read-only for the first time. But, it gets rw
> afterwards.
That doesn't seem to matter. It has definitely to be mounted rw for the
first time. Is it / will it be in the docs?
>
> If I understood you correctly: The first time after "this poweroff" the
> partition has to be mounted rw in order to complete the unlinks?
> The uncompleted unlinks I have on disk will stay until next --rebuild-tree?
No, they get automatically completed on next mount!
>
> I would be glad, if you could comment this mail.
Done? Solved! Great!
>
> Thank you, I'll check it out now!
>
> Manuel
>
Many thanks for your work and your patience with me!
Very best regards,
Manuel
