On 07/29/2001 09:00 PM, Manuel Krause wrote:
> 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
>
Sorry, I didn't go through all text and cut away most/unneeded lines...
Is it possible to implement "completing uncompleted unlinks/truncates"
within a "mount -o remount,rw ..." ?
I really don't know how usual it is -- this first mounting ro and later
on, when fsck on ext2 partitions is over, remounting rw. SuSE has it (at
least) until 7.1 in /etc/rc.d/boot script and /etc/lilo.conf by default.
So it may be on other distros, too?
What I think of: Of course, reiserfs users should regularily check
www.namesys.com/www.reiserfs.com/.org, the ML and the manpages - but if
reiserfs is shipped with distros that offer reiserfs AND mounting ro by
default... one party should change their defaults or setups, IMO.
If newbies try 2.4.7-plain-kernel, vmware, get the recent 2.4.7 patch
for vmware-modules, encounter a crash with new pre-compiled XF86
binaries... Mmmh, ok, I see it's getting heavily unrealistic now...
But in case vmware worked correctly with the actual kernel or they
finally put a hint/link on their website, they'll go to the distros
support or to you with complaints.
It's worth a thought though, doesn't it?!
Thanks,
Manuel
