Re: BTW: 2.4.19-patches-to-come?

Re: BTW: 2.4.19-patches-to-come?

[Dieter Nützel]

[-- Attachment #1: Type: text/plain, Size: 6338 bytes --]

On Friday 17 May 2002 09:47, oleg Drokin wrote:
>Hello!
>
>On Fri, May 17, 2002 at 03:49:06AM +0200, Manuel Krause wrote:
>
> > I was curious and I stay curious, as I don't see any program deleting 3 
> > files just before every crash...  (I don't have sizes, places and
> > names...)
>
> It is not necessarily happened to files direectly to a crash.
> Any open file, that was deleted, cannot be deleted until it is closed.
> e.g. if you'd do "sleep 1000000 </path/somefile ; rm /path/somefile",
> /path/somefile won't be deleted until sleep finishes.
> If system crash occured and there were still some open, but deleted files,
> these files gets removed as part of recovery from crash process.
> And it is not possible to find file's names/paths because corresponding
> directory entries were already deleted.
>
> BTW it is absolutely the same thing happens with ext2, once you see
> e2fsck complains about "DTIME is zero", it deletes
> not-yet-deleted-but-scheduled-for-deletion files.

Sorry Oleg, that I jump in, here...

I get from time to time corrupted files (after reboot and replay) which are 
_NOT_ written during/before crash!!!
It happes during huge C++ compilation of one of my 3D VIS apps.

After reboot I have waste in the original *.cxx files. This is very strange 
and time consuming 'cause I have to remove every broken file by hand and 
recreate it with CVS when the compiler hit it during the next run.

A similar thing happen during kernel compilations.
When the system crash (due to kernel devel stuff) some *.o or mostly 
.*.o.flags files are broken after replay/reboot. Yes, this time they are 
written before/during crash and rebuild during replay, but it should much 
more usefull if they were only _REMOVED_ during replay. Because the "next" 
kernel build can't run smooth without "make clean" or deletion by hand.
What do you think?

Here comes how it looks after C++ case:

c++ -O -mcpu=k6 -pipe -mpreferred-stack-boundary=2 -malign-functions=4 
-fschedule-insns2 -fexpensive-optimizations -DvtkRenderingPython_EXPORTS 
-fPIC -I/opt/VTK/V4.0/VTK/Rendering -I/opt/VTK/V4.0/VTK/Rendering 
-I/opt/VTK/V4.0/VTK/Hybrid -I/opt/VTK/V4.0/VTK/Patented -I/opt/VTK/V4.0/VTK 
-I/opt/VTK/V4.0/VTK/Common -I/opt/VTK/V4.0/VTK/Filtering 
-I/opt/VTK/V4.0/VTK/Imaging -I/opt/VTK/V4.0/VTK/Graphics 
-I/opt/VTK/V4.0/VTK/IO -I/opt/VTK/V4.0/VTK/Utilities/zlib 
-I/opt/VTK/V4.0/VTK/Utilities/png -I/opt/VTK/V4.0/VTK/Utilities/jpeg 
-I/opt/VTK/V4.0/VTK/Utilities/tiff -I/opt/VTK/V4.0/VTK/Utilities/expat 
-I/opt/VTK/V4.0/VTK/Common/Testing/Cxx -I/usr/include/python2.1    
-I/usr/X11R6/include -c 
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballCameraPython.cxx -o 
vtkInteractorStyleTrackballCameraPython.o
make[3]: *** [vtkInteractorStyleJoystickActorPython.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: *** [vtkInteractorStyleJoystickCameraPython.o] Error 1
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballPython.cxx:1: parse 
error before `%'
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballPython.cxx:4: character 
constant too long
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballPython.cxx:4: unknown 
escape sequence: `\' followed by char code 0xe
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballPython.cxx:17: 
character constant too long
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballPython.cxx:17: 
character constant too long
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballPython.cxx:44: 
character constant too long
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballActorPython.cxx:1: 
unterminated character constant
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballActorPython.cxx:14: 
unterminated character constant
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballPython.cxx:44: unknown 
escape sequence `\@'
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballPython.cxx:44: 
character constant too long
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballPython.cxx:44: 
nondigits in number and not hexadecimal
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballPython.cxx:44: 
nondigits in number and not hexadecimal
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballPython.cxx:44: 
character constant too long
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballCameraPython.cxx:43: 
unterminated string or character constant
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballCameraPython.cxx:43: 
possible real start of unterminated constant
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballCameraPython.cxx:1: 
syntax error before `('
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballCameraPython.cxx:42: 
character constant too long
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballActorPython.cxx:1: 
parse error before `0'
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballActorPython.cxx:2: 
character constant too long
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballActorPython.cxx:2: 
nondigits in number and not hexadecimal
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballActorPython.cxx:2: 
nondigits in number and not hexadecimal
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballActorPython.cxx:2: 
unknown escape sequence: `\' followed by char code 0x91
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballActorPython.cxx:2: 
character constant too long
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballActorPython.cxx:6: 
character constant too long
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballActorPython.cxx:6: 
unknown escape sequence: `\' followed by char code 0xf
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballActorPython.cxx:14: 
character constant too long
/opt/VTK/V4.0/VTK/Rendering/vtkInteractorStyleTrackballActorPython.cxx:43: 
character constant too long
make[3]: *** [vtkInteractorStyleTrackballPython.o] Error 1
make[2]: *** [default_target] Error 2
make[1]: *** [default_target_Rendering] Error 2
make: *** [default_target] Error 2

Have a look into the falsely "rebuild" broken files in the attachment, too.

Thanks,
	Dieter
-- 
Dieter Nützel
Graduate Student, Computer Science

University of Hamburg
Department of Computer Science
@home: Dieter.Nuetzel@hamburg.de


[-- Attachment #2: vtkInteractorStylePython.cxx.bz2 --]
[-- Type: application/x-bzip2, Size: 9339 bytes --]

[-- Attachment #3: vtkInteractorStyleTrackballPython.cxx.bz2 --]
[-- Type: application/x-bzip2, Size: 4932 bytes --]

Re: BTW: 2.4.19-patches-to-come?

[Chris Mason]

On Fri, 2002-05-17 at 11:36, Dieter Nützel wrote:

> Sorry Oleg, that I jump in, here...
> 
> I get from time to time corrupted files (after reboot and replay) which are 
> _NOT_ written during/before crash!!!
> It happes during huge C++ compilation of one of my 3D VIS apps.
> 
> After reboot I have waste in the original *.cxx files. This is very strange 
> and time consuming 'cause I have to remove every broken file by hand and 
> recreate it with CVS when the compiler hit it during the next run.

Is this on IDE?  With tails turned on?  Are all the affected files less
than 16k?

> 
> A similar thing happen during kernel compilations.
> When the system crash (due to kernel devel stuff) some *.o or mostly 
> .*.o.flags files are broken after replay/reboot. Yes, this time they are 
> written before/during crash and rebuild during replay, 

This will be taken care of by the data=ordered patches.  I'm combining
them with the data logging stuff.

-chris

Re: BTW: 2.4.19-patches-to-come?

[Dieter Nützel]

On Friday 17 May 2002 17:47, Chris Mason wrote:
> On Fri, 2002-05-17 at 11:36, Dieter Nützel wrote:
> > Sorry Oleg, that I jump in, here...
> >
> > I get from time to time corrupted files (after reboot and replay) which
> > are _NOT_ written during/before crash!!!
> > It happes during huge C++ compilation of one of my 3D VIS apps.
> >
> > After reboot I have waste in the original *.cxx files. This is very
> > strange and time consuming 'cause I have to remove every broken file by
> > hand and recreate it with CVS when the compiler hit it during the next
> > run.
>
> Is this on IDE?

What? Never ever had such "things" on my private system...;-)

If you need the ultimative U160 disk look at the Fujitsu MAM3184 (18 GB) or 
the bigger brother (36 GB). 15k RPM, 3.5 ms  read, 4.0 ms write, silent like 
the current ATA-5/6 (!!!) and fast as hell (max 88.9 MB/s) disk transfer rate 
(!!!). Sadly my old AHA-2940UW can't handle them correctly even as they 
should "down compatible". Time for a real U160 controller (any 
bounties?)...-;)

> With tails turned on?

Not at all.

/dev/sda3 on / type reiserfs (rw,noatime,notail)
/dev/sda2 on /tmp type reiserfs (rw,notail)
/dev/sda5 on /var type reiserfs (rw,notail)
/dev/sda6 on /home type reiserfs (rw,notail)
/dev/sda7 on /usr type reiserfs (rw,notail)
/dev/sda8 on /opt type reiserfs (rw,notail)
/dev/sdb1 on /Pakete type reiserfs (rw,notail)
/dev/sdb5 on /database/db1 type reiserfs (rw,notail)
/dev/sdb6 on /database/db2 type reiserfs (rw,notail)
/dev/sdb7 on /database/db3 type reiserfs (rw,notail)
/dev/sdb8 on /database/db4 type reiserfs (rw,notail)

> Are all the affected files less than 16k?

I have to recheck (regenerate the "test case" --- push the power button).

To be precise I got this with and without the data logging patch applied but I 
haven't mounted with data logging.

Most (all) former kernel versions with and without preemption+lock-break shown 
the same.

> > A similar thing happen during kernel compilations.
> > When the system crash (due to kernel devel stuff) some *.o or mostly
> > .*.o.flags files are broken after replay/reboot. Yes, this time they are
> > written before/during crash and rebuild during replay,
>
> This will be taken care of by the data=ordered patches.  I'm combining
> them with the data logging stuff.

Ah, then it's time for my data logging results.

See it in my next post.

-Dieter

Re: BTW: 2.4.19-patches-to-come?

[Dieter Nützel]

On Friday 17 May 2002 20:20, Dieter Nützel wrote:
> On Friday 17 May 2002 17:47, Chris Mason wrote:
> > On Fri, 2002-05-17 at 11:36, Dieter Nützel wrote:
> > > Sorry Oleg, that I jump in, here...

> > Are all the affected files less than 16k?
>
> I have to recheck (regenerate the "test case" --- push the power button).

Ups, see the two attached files, again.
One is below 16k, the other above.

-Dieter

Re: Re: BTW: 2.4.19-patches-to-come?

[Chris Mason]

On Fri, 2002-05-17 at 14:20, Dieter Nützel wrote:
> On Friday 17 May 2002 17:47, Chris Mason wrote:
> > On Fri, 2002-05-17 at 11:36, Dieter Nützel wrote:
> > > Sorry Oleg, that I jump in, here...
> > >
> > > I get from time to time corrupted files (after reboot and replay) which
> > > are _NOT_ written during/before crash!!!
> > > It happes during huge C++ compilation of one of my 3D VIS apps.
> > >
> > > After reboot I have waste in the original *.cxx files. This is very
> > > strange and time consuming 'cause I have to remove every broken file by
> > > hand and recreate it with CVS when the compiler hit it during the next
> > > run.
> >
> > Is this on IDE?
> 
> What? Never ever had such "things" on my private system...;-)

Ah.  What I was hoping for was that tail conversions + writeback caching
were causing these corrupted files.  Clearly that isn't the case.  I'd
be really interested to see if you could reproduce on a vanilla kernel.

-chris

Re: BTW: 2.4.19-patches-to-come?

[Oleg Drokin]

Hello!

On Fri, May 17, 2002 at 05:36:50PM +0200, Dieter N?tzel wrote:

> > It is not necessarily happened to files direectly to a crash.
> > Any open file, that was deleted, cannot be deleted until it is closed.
> > e.g. if you'd do "sleep 1000000 </path/somefile ; rm /path/somefile",
> > /path/somefile won't be deleted until sleep finishes.
> > If system crash occured and there were still some open, but deleted files,
> > these files gets removed as part of recovery from crash process.
> > And it is not possible to find file's names/paths because corresponding
> > directory entries were already deleted.
> > BTW it is absolutely the same thing happens with ext2, once you see
> > e2fsck complains about "DTIME is zero", it deletes
> > not-yet-deleted-but-scheduled-for-deletion files.
> Sorry Oleg, that I jump in, here...
> I get from time to time corrupted files (after reboot and replay) which are 
> _NOT_ written during/before crash!!!

What is the corruption pattern?

> It happes during huge C++ compilation of one of my 3D VIS apps.

atime is still updated, I think. What was the crash, btw?
Hard power loss?

> A similar thing happen during kernel compilations.
> When the system crash (due to kernel devel stuff) some *.o or mostly 
> .*.o.flags files are broken after replay/reboot. Yes, this time they are 

This is expected.

> written before/during crash and rebuild during replay, but it should much 
> more usefull if they were only _REMOVED_ during replay. Because the "next" 
> kernel build can't run smooth without "make clean" or deletion by hand.
> What do you think?

These files are not deleted, so why fs should delete these?

> Have a look into the falsely "rebuild" broken files in the attachment, too.

Later today

Bye,
    Oleg

Re: BTW: 2.4.19-patches-to-come?

[Dieter Nützel]

On Friday 17 May 2002 17:54, Oleg Drokin wrote:
> Hello!
>
> On Fri, May 17, 2002 at 05:36:50PM +0200, Dieter N?tzel wrote:
> > > It is not necessarily happened to files direectly to a crash.
> > > Any open file, that was deleted, cannot be deleted until it is closed.
> > > e.g. if you'd do "sleep 1000000 </path/somefile ; rm /path/somefile",
> > > /path/somefile won't be deleted until sleep finishes.
> > > If system crash occured and there were still some open, but deleted
> > > files, these files gets removed as part of recovery from crash process.
> > > And it is not possible to find file's names/paths because corresponding
> > > directory entries were already deleted.
> > > BTW it is absolutely the same thing happens with ext2, once you see
> > > e2fsck complains about "DTIME is zero", it deletes
> > > not-yet-deleted-but-scheduled-for-deletion files.
> >
> > Sorry Oleg, that I jump in, here...
> > I get from time to time corrupted files (after reboot and replay) which
> > are _NOT_ written during/before crash!!!
>
> What is the corruption pattern?

Have a look into the two examples.

> > It happes during huge C++ compilation of one of my 3D VIS apps.
>
> atime is still updated, I think.

Yes, could be the case. The partition is not mounted with "noatime".

> What was the crash, btw?
> Hard power loss?

No.
"Only" hard lookup. Sadly SysReq is not working ;-(

> > A similar thing happen during kernel compilations.
> > When the system crash (due to kernel devel stuff) some *.o or mostly
> > .*.o.flags files are broken after replay/reboot. Yes, this time they are
>
> This is expected.
>
> > written before/during crash and rebuild during replay, but it should much
> > more usefull if they were only _REMOVED_ during replay. Because the
> > "next" kernel build can't run smooth without "make clean" or deletion by
> > hand. What do you think?
>
> These files are not deleted, so why fs should delete these?

Yes, you are right. But semantically they are worthless 'cause they are 
"broken"...

> > Have a look into the falsely "rebuild" broken files in the attachment,
> > too.
>
> Later today

Hey, it's weekend then...;-)

Happy Whitsun everyone!

Regards,
	Dieter

Re: BTW: 2.4.19-patches-to-come?

[Oleg Drokin]

Hello!

On Fri, May 17, 2002 at 07:05:30PM +0200, Dieter N?tzel wrote:
> > What is the corruption pattern?
> Have a look into the two examples.

I will, but later, it seems.

> > What was the crash, btw?
> > Hard power loss?
> No.
> "Only" hard lookup. Sadly SysReq is not working ;-(

And you fix it by "reset switch"?

BTW, Was that you with a kernel with lot of patches applied, or
you do not use anything strange on your workstations?

> > > written before/during crash and rebuild during replay, but it should much
> > > more usefull if they were only _REMOVED_ during replay. Because the
> > > "next" kernel build can't run smooth without "make clean" or deletion by
> > > hand. What do you think?
> > These files are not deleted, so why fs should delete these?
> Yes, you are right. But semantically they are worthless 'cause they are 
> "broken"...

FS cannot know this. Absolutely cannot.
File was created, written into. So file appears after reboot (if transaction
in which it was created was commited).
BTW, I have a feeling that datalogging patches would help to get rid of
garbage in the files, but files still will remain (may be of zero length).

> > > Have a look into the falsely "rebuild" broken files in the attachment,
> > > too.
> > Later today
> Hey, it's weekend then...;-)

So what? ;)

> Happy Whitsun everyone!

Hm. What's that? ;)

Bye,
    Oleg

Re: BTW: 2.4.19-patches-to-come?

[Dieter Nützel]

On Friday 17 May 2002 20:28, Oleg Drokin wrote:
> Hello!
>
> On Fri, May 17, 2002 at 07:05:30PM +0200, Dieter N?tzel wrote:
> > > What is the corruption pattern?
> >
> > Have a look into the two examples.
>
> I will, but later, it seems.
>
> > > What was the crash, btw?
> > > Hard power loss?
> >
> > No.
> > "Only" hard lookup. Sadly SysReq is not working ;-(
>
> And you fix it by "reset switch"?

Yes, but fix? 8-)
System come up "normal" do the replay and is smooth except of the "few" broken 
files.

> BTW, Was that you with a kernel with lot of patches applied, or
> you do not use anything strange on your workstations?

Yes, but it happen with and without data logging, preemption, aa_VM, etc.

I can reproduce it with some "new" page coloring stuff (only).
When I modprobe the page coloring module (it is under development) the system 
lookup from time to time during heavy (parallel) compilation for example.
Then I get the broken files.

> > > > written before/during crash and rebuild during replay, but it should
> > > > much more usefull if they were only _REMOVED_ during replay. Because
> > > > the "next" kernel build can't run smooth without "make clean" or
> > > > deletion by hand. What do you think?
> > >
> > > These files are not deleted, so why fs should delete these?
> >
> > Yes, you are right. But semantically they are worthless 'cause they are
> > "broken"...
>
> FS cannot know this. Absolutely cannot.

Yes, I know for sure.

> File was created, written into. So file appears after reboot (if
> transaction in which it was created was commited).

Maybe the FS should have some knowledge "build in" to "decide" that *.o files 
are "temperär" and should be removed during replay?

> BTW, I have a feeling that datalogging patches would help to get rid of
> garbage in the files, but files still will remain (may be of zero length).

Yes, Chris said this, too.

>
> > > > Have a look into the falsely "rebuild" broken files in the
> > > > attachment, too.
> > >
> > > Later today
> >
> > Hey, it's weekend then...;-)
>
> So what? ;)

:-)

> > Happy Whitsun everyone!
>
> Hm. What's that? ;)

Here in Germany the two Whitsun days Sunday and Monday are (high christian) 
feasts and most people are out for short vacation.

-Dieter

BTW I have to work, tomorrow ;-)

Re: BTW: 2.4.19-patches-to-come?

[Oleg Drokin]

Hello!

On Fri, May 17, 2002 at 09:44:21PM +0200, Dieter N?tzel wrote:

> > BTW, Was that you with a kernel with lot of patches applied, or
> > you do not use anything strange on your workstations?
> Yes, but it happen with and without data logging, preemption, aa_VM, etc.
> I can reproduce it with some "new" page coloring stuff (only).
> When I modprobe the page coloring module (it is under development) the system 
> lookup from time to time during heavy (parallel) compilation for example.
> Then I get the broken files.

Well, sounds like page colouring stuff mistakenly writes some pages in wrong
location, no?
If you cannot reproduce without page colouring patch, that would be the most
probably theory, I'd say.

> > File was created, written into. So file appears after reboot (if
> > transaction in which it was created was commited).
> Maybe the FS should have some knowledge "build in" to "decide" that *.o files 
> are "temper?r" and should be removed during replay?

No, there is absolutely no way for such kludges to go into the FS, I think.
And it even may be the case where .o file was created, commited, and then
journal record obsoletted, because metadata got it's way to the disk,
so file is already in place (without the body, or with garbage instead
of the body), but it have nothing to do with journal.

> > BTW, I have a feeling that datalogging patches would help to get rid of
> > garbage in the files, but files still will remain (may be of zero length).
> Yes, Chris said this, too.

He said it will help your problem, I think. But zero length .o files will
still confuse linker.

Bye,
    Oleg

Re: BTW: 2.4.19-patches-to-come?

[Dieter Nützel]

On Saturday 18 May 2002 07:44, Oleg Drokin wrote:
> Hello!
>
> On Fri, May 17, 2002 at 09:44:21PM +0200, Dieter N?tzel wrote:
> > > BTW, Was that you with a kernel with lot of patches applied, or
> > > you do not use anything strange on your workstations?
> >
> > Yes, but it happen with and without data logging, preemption, aa_VM, etc.
> > I can reproduce it with some "new" page coloring stuff (only).
> > When I modprobe the page coloring module (it is under development) the
> > system lookup from time to time during heavy (parallel) compilation for
> > example. Then I get the broken files.
>
> Well, sounds like page colouring stuff mistakenly writes some pages in
> wrong location, no?

Yes, that could be the case.

> If you cannot reproduce without page colouring patch, that would be the
> most probably theory, I'd say.

That isn't what I've said. I only said I can "reproduce" the kernel crash with 
page coloring the easiest way.

The problem of broken files appear during "any" kernel crash which I get from 
time to time during devel kernel stuff testing/developing.

> > > File was created, written into. So file appears after reboot (if
> > > transaction in which it was created was commited).
> >
> > Maybe the FS should have some knowledge "build in" to "decide" that *.o
> > files are "temper?r" and should be removed during replay?
>
> No, there is absolutely no way for such kludges to go into the FS, I think.
> And it even may be the case where .o file was created, commited, and then
> journal record obsoletted, because metadata got it's way to the disk,
> so file is already in place (without the body, or with garbage instead
> of the body), but it have nothing to do with journal.

I understand this very well, but "all" talking about making computer systems 
and FSs more "intelligent"...;-)

> > > BTW, I have a feeling that datalogging patches would help to get rid of
> > > garbage in the files, but files still will remain (may be of zero
> > > length).
> >
> > Yes, Chris said this, too.
>
> He said it will help your problem, I think. But zero length .o files will
> still confuse linker.

So what's your advice then? Mounting all FSs with "noatime"?

Thanks,
	Dieter

Re: BTW: 2.4.19-patches-to-come?

[Oleg Drokin]

Hello!

On Sat, May 18, 2002 at 03:18:23PM +0200, Dieter N?tzel wrote:
> > > I can reproduce it with some "new" page coloring stuff (only).
> > > When I modprobe the page coloring module (it is under development) the
> > > system lookup from time to time during heavy (parallel) compilation for
> > > example. Then I get the broken files.
> > Well, sounds like page colouring stuff mistakenly writes some pages in
> > wrong location, no?
> Yes, that could be the case.
> > If you cannot reproduce without page colouring patch, that would be the
> > most probably theory, I'd say.
> That isn't what I've said. I only said I can "reproduce" the kernel crash with 
> page coloring the easiest way.

Sorry, I misinterpreted it, then. Perhaps I was confused by "only" word in sentence above.

> > > > BTW, I have a feeling that datalogging patches would help to get rid of
> > > > garbage in the files, but files still will remain (may be of zero
> > > > length).
> > > Yes, Chris said this, too.
> >
> > He said it will help your problem, I think. But zero length .o files will
> > still confuse linker.
> So what's your advice then? Mounting all FSs with "noatime"?

noatime have nothing to do with wrong content of recently created files after
crash.
It was only my guess that atime updates might have caused corruptions on file
read. But you are not using IDE. Anyway, you can try and tell us.

Bye,
    Oleg

Re: Re: BTW: 2.4.19-patches-to-come?

[Manuel Krause]

On 05/18/2002 06:29 PM, Oleg Drokin wrote:

> Hello!
> 
> On Sat, May 18, 2002 at 03:18:23PM +0200, Dieter N?tzel wrote:
> 
>>>>I can reproduce it with some "new" page coloring stuff (only).
>>>>When I modprobe the page coloring module (it is under development) the
>>>>system lookup from time to time during heavy (parallel) compilation for
>>>>example. Then I get the broken files.
>>>>
>>>Well, sounds like page colouring stuff mistakenly writes some pages in
>>>wrong location, no?
>>>
>>Yes, that could be the case.
>>
>>>If you cannot reproduce without page colouring patch, that would be the
>>>most probably theory, I'd say.
>>>
>>That isn't what I've said. I only said I can "reproduce" the kernel crash with 
>>page coloring the easiest way.
>>
> 
> Sorry, I misinterpreted it, then. Perhaps I was confused by "only" word in sentence above.
> 
> 
>>>>>BTW, I have a feeling that datalogging patches would help to get rid of
>>>>>garbage in the files, but files still will remain (may be of zero
>>>>>length).
>>>>>
>>>>Yes, Chris said this, too.
>>>>
>>>He said it will help your problem, I think. But zero length .o files will
>>>still confuse linker.
>>>
>>So what's your advice then? Mounting all FSs with "noatime"?
>>
> 
> noatime have nothing to do with wrong content of recently created files after
> crash.
> It was only my guess that atime updates might have caused corruptions on file
> read. But you are not using IDE. Anyway, you can try and tell us.
> 
> Bye,
>     Oleg
> 


Thank you all, for keeping me informed, too!

I have all my partitions mounted -o [...+]noatime and the reiserfs ones 
with [+]notail since many years as it was said to bring a performance 
gain (never proved it myself). As I get same errors as Dieter but on IDE 
disks (!)... that "noatime" might not solve the problem for recently 
accessed files (like it may occur on a crash with a running KDE with its 
setup files, too).

Though having some *.o files when a kernel-or-so compile fails and I 
need to make a "make mrproper", e.g., to get it in order again I don't 
want them all to be removed "intelligently" by the FS. Oleg, you 
explained it  right. I don't want some files vanishing completely upon 
intermediate crash (so, even if not everything has been built and I may 
need to recompile or reset /all/ after restart). But in fact it can be 
very complicated to find the corrupted=broken-but-not-deleted file 
sometimes.


Oleg, another approach to the original topics' problems as I can't say 
what files are accessed and unlinked/deleted before crash with sense 
with my typical crash pattern: How can I try to monitor accessed files 
just before my typical crash patterns (to see what reiserfs makes of 
them after crash)?
I really want to watch what gets restored, recovered or deleted if 
possible. So far I don't get a logic from your explanations to my 
ReiserFS' behaviour on this, sorry, though I understood your and Chris 
words on this. Is there a way to do this "snapshot"?

Dieter, do you have a time relation of your crashes? I mean e.g. related 
in secs or mins after system startup? My "most loved crashes" 
(without-page-colouring, of course) occur approx. 2min after startup 
with full Seti-load or formerly on a "make bzlilo" without "sync" after 
"make bzImage" (formerly = "with unusable bdflush and harddisk settings").

Chris, can we have an answer on Dieters questions ("What's wrong?") in 
thread "[reiserfs-list] Re: data-logging on top of 
linux-2.4.19p7-compound-speedup-2.patch", and a notification on your 
future patchset for latest official reiserfs stuff, thank you! Really, 
with your patches from ftp.suse.com I did not feel well adjusting lines 
by hand (see Dieters questions on this...)


Bye, and thanks, again,
have a nice Whitsun (never new the english words and that explanation 
before Dieter mentionning it, have to work all-day though, too, thanks!)


Manuel

Re: Re: BTW: 2.4.19-patches-to-come?

[Oleg Drokin]

Hello!

On Sat, May 18, 2002 at 11:44:55PM +0200, Manuel Krause wrote:

> Oleg, another approach to the original topics' problems as I can't say 
> what files are accessed and unlinked/deleted before crash with sense 
> with my typical crash pattern: How can I try to monitor accessed files 
> just before my typical crash patterns (to see what reiserfs makes of 
> them after crash)?

Since usually you cannot reliable predict a crash time (note, that if you
can and it is SW fault, you should file a bug report instead, I think).

> I really want to watch what gets restored, recovered or deleted if 
> possible. So far I don't get a logic from your explanations to my 

You get keys of all objects truncated or deleted during mount.
deleted keys won't help you as they are deleted, truncated files can be found
by tjeir key (e.g. debugreiserfs -d /dev/hda and look for the first 2 
numbers in a key).

> ReiserFS' behaviour on this, sorry, though I understood your and Chris 
> words on this. Is there a way to do this "snapshot"?

I think Chris said you can get a snapshot using intermezzo + datalogging patchs
from Chris.

> Dieter, do you have a time relation of your crashes? I mean e.g. related 
> in secs or mins after system startup? My "most loved crashes" 
> (without-page-colouring, of course) occur approx. 2min after startup 
> with full Seti-load or formerly on a "make bzlilo" without "sync" after 
> "make bzImage" (formerly = "with unusable bdflush and harddisk settings").

You mean, once you start CPU-intensive task, everything dies pretty soon?
Are you sure you do not have hardware/overheating problems.
I had a problem on my WS, if I'd run 20 instances of
while :; do:; done
my WS would hang in under 5 minutes. This was fixed by adding 2
extra cooles to the case.

Bye,
    Oleg

Re: Re: BTW: 2.4.19-patches-to-come?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 309 bytes --]

On Sun, 19 May 2002 13:44:54 +0400, Oleg Drokin said:

> Since usually you cannot reliable predict a crash time (note, that if you
> can and it is SW fault, you should file a bug report instead, I think).

Wasn't there a Dilbert cartoon about a PHB that wanted advance announcement
of unscheduled outages? ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

BTW: 2.4.19-patches-to-come?

[Manuel Krause]

Hi!

BTW, for 2.4.19-final it would be very nice to have...

1.) the deleted/truncated/completed-files-on-mount at least
     printed in the kernel logs, at best with the real filename
     -- as afterwards they are not retrievable --
     That's a security reason -- whoever can trigger a crash
     with various methods (I know the admin should take care
     against this case... but on my home sytem I'd like to know
     that info, too) but to get back the file from backups in
     case... who knows it before a
     crash... ? Am I missing something?

2.) a disk/drive/partition distinction in reiserfs related
     messages -- Oleg, you promised it to get real and best
     would be a real "patch" !

3.) a hint on how to turn on/off data-journaling for "some"
     of our existing reiserfs partitions if it exists at all
     for now and why it could be needed in some cases?!.

4.) a hint why there is iicache code in the latest
     speedup-compound-patch (so that the latest iicache patch
     would not apply)


Best regards for your stable ReiserFS, at all,

even under "settings" with 2.4.19-pre7 +reiserfs.pending +latest 
reiserfs.compound-speedup +aa.vm-for-2.4.19-pre7 +akpm.read-latency-2 
+rml.preempt-kernel + rml.lock-break +some-more nice aa.patches... 
That's a valuably fast & interactive experience!


Manuel

Re: BTW: 2.4.19-patches-to-come?

[Oleg Drokin]

Hello!

On Tue, May 07, 2002 at 03:15:29AM +0200, Manuel Krause wrote:

> 1.) the deleted/truncated/completed-files-on-mount at least
>     printed in the kernel logs, at best with the real filename

Huh??

>     -- as afterwards they are not retrievable --

Sure. Files are deleted already. How do you plan to retrieve deleted files?
(not using backups, that's it).

>     That's a security reason -- whoever can trigger a crash
>     with various methods (I know the admin should take care
>     against this case... but on my home sytem I'd like to know
>     that info, too) but to get back the file from backups in
>     case... who knows it before a
>     crash... ? Am I missing something?

This is unclear to me. You mean to crash a system to get a copy of deleted file,
or to crash a system to delete a file? Both things sound very unlikely.

> 2.) a disk/drive/partition distinction in reiserfs related
>     messages -- Oleg, you promised it to get real and best
>     would be a real "patch" !

Yes, I remember.

> 3.) a hint on how to turn on/off data-journaling for "some"
>     of our existing reiserfs partitions if it exists at all
>     for now and why it could be needed in some cases?!.

Data journaling is available only in form of a separate patch from Chris for
now.

> 4.) a hint why there is iicache code in the latest
>     speedup-compound-patch (so that the latest iicache patch
>     would not apply)

Hm? What do you mean by latest speedup-compound-patch? I know Chris does not
believe iicache should be good to use, because similar functionality (with
less overhead) can be achieved by pagecache.

Bye,
    Oleg

Re: BTW: 2.4.19-patches-to-come?

[Yury Yu. Rupasov]

Oleg Drokin wrote:

> Hello!
>
> On Tue, May 07, 2002 at 03:15:29AM +0200, Manuel Krause wrote:
>
> > 1.) the deleted/truncated/completed-files-on-mount at least
> >     printed in the kernel logs, at best with the real filename
>
> Huh??
>
> >     -- as afterwards they are not retrievable --
>
> Sure. Files are deleted already. How do you plan to retrieve deleted files?
> (not using backups, that's it).
>
> >     That's a security reason -- whoever can trigger a crash
> >     with various methods (I know the admin should take care
> >     against this case... but on my home sytem I'd like to know
> >     that info, too) but to get back the file from backups in
> >     case... who knows it before a
> >     crash... ? Am I missing something?
>
> This is unclear to me. You mean to crash a system to get a copy of deleted file,
> or to crash a system to delete a file? Both things sound very unlikely.
>
> > 2.) a disk/drive/partition distinction in reiserfs related
> >     messages -- Oleg, you promised it to get real and best
> >     would be a real "patch" !
>
> Yes, I remember.
>
> > 3.) a hint on how to turn on/off data-journaling for "some"
> >     of our existing reiserfs partitions if it exists at all
> >     for now and why it could be needed in some cases?!.
>
> Data journaling is available only in form of a separate patch from Chris for
> now.
>
> > 4.) a hint why there is iicache code in the latest
> >     speedup-compound-patch (so that the latest iicache patch
> >     would not apply)
>
> Hm? What do you mean by latest speedup-compound-patch? I know Chris does not
> believe iicache should be good to use, because similar functionality (with
> less overhead) can be achieved by pagecache.
>

I think it is :
ftp://ftp.namesys.com/pub/reiserfs-for-2.4/testing/linux-2.4.19p7-compound-speedup-2.patch

It contains Chris's sppedup patch, Oleg's hole_sppedup patch
and iicache patch.

All other speedup approaches are welcome of course.

Thanks,
Yura

Re: BTW: 2.4.19-patches-to-come?

[Manuel Krause]

Hi!

On 05/07/2002 07:22 AM, Oleg Drokin wrote:

> Hello!
> 
> On Tue, May 07, 2002 at 03:15:29AM +0200, Manuel Krause wrote:
> 
> 
>>1.) the deleted/truncated/completed-files-on-mount at least
>>    printed in the kernel logs, at best with the real filename
>>
> 
> Huh??
> 
>>    -- as afterwards they are not retrievable --
>>
> 
> Sure. Files are deleted already. How do you plan to retrieve deleted files?
> (not using backups, that's it).
> 


Mmh. I meant to restore the affected files from existing backups. When
they are  removed by reiserfs on mount I know they are really corrupted
during crash. It often looks like:
  Removing [5523 5570 0x0 SD]..done
  Removing [5523 5569 0x0 SD]..done
  Removing [5523 5566 0x0 SD]..done
  There were 3 uncompleted unlinks/truncates. Completed

I have an overview what files may be meant but... See the context below.
I don't find this information very explicative. And I really don't know
enough about reiserfs code to interprete these lines. BTW, can we have a
"ReiserFS: " in front of these messages?

> 
>>    That's a security reason -- whoever can trigger a crash
>>    with various methods (I know the admin should take care
>>    against this case... but on my home sytem I'd like to know
>>    that info, too) but to get back the file from backups in
>>    case... who knows it before a
>>    crash... ? Am I missing something?
>>
> 
> This is unclear to me. You mean to crash a system to get a copy of deleted file,
> or to crash a system to delete a file? Both things sound very unlikely.
> 


Yes, no doubt, I really don't know what is usual in these cases. I
should explain what happened to make me write this comment. I had
recompiled one DRI module for X recently when my system decided to
crash. After rebooot I had some truncates-to-complete. So far "normal"
or at least "o.k.".

But due to anti-aliasing configured in KDE it loaded everything but
didn't show anything else than my desktops background color and the
mouse arrow. It took me some time to figure out how to get things back
into previous order. It finally seems like I just needed to reinstall
the DRI component. But until now I don't know what files had
disappeared/corrupted to get exactly and only these ones from my backup.
You see? Yes, not usual, but...

> 
[disk distinction]
>>3.) a hint on how to turn on/off data-journaling for "some"
>>    of our existing reiserfs partitions if it exists at all
>>    for now and why it could be needed in some cases?!.
>>
> 
> Data journaling is available only in form of a separate patch from Chris for
> now.
> 


Yes, thanks, Chris gave that info, too. Thank you! I mostly (only)
wondered about Hans' & Chris' discussion about not yet implemented and
not released-on-Namesys-ftp-for-testing reiserfs options that seem to be
useful in some cases...

> 
>>4.) a hint why there is iicache code in the latest
>>    speedup-compound-patch (so that the latest iicache patch
>>    would not apply)
>>
> 
> Hm? What do you mean by latest speedup-compound-patch? I know Chris does not
> believe iicache should be good to use, because similar functionality (with
> less overhead) can be achieved by pagecache.
> 


Pagecache? How can I adjust this? Where did I read this before...?

Yura explained what patch I meant. Hey, that's on Namesys ftp for one
week already!

 >

> Bye,
>     Oleg
> 

Bye,

Manuel

Re: BTW: 2.4.19-patches-to-come?

[Oleg Drokin]

Gwllo!

On Tue, May 07, 2002 at 09:35:18PM +0200, Manuel Krause wrote:

> >Sure. Files are deleted already. How do you plan to retrieve deleted files?
> >(not using backups, that's it).
> Mmh. I meant to restore the affected files from existing backups. When

Then you just see what files are missing and restore these.

> they are  removed by reiserfs on mount I know they are really corrupted
> during crash. It often looks like:
Wait-wait. They are removed, so their blocks are freed and may be replaced
with other files data. Removing files is like this.
Late deletion is because application that deleted the file kept it open
until the reboot.
And no, it's not even possible to print filename at this point, because
all the links (And dierctory items) pointing at the file were already removed,
only unacessible body with nlink count of zero was left.

> I don't find this information very explicative. And I really don't know
> enough about reiserfs code to interprete these lines. BTW, can we have a
> "ReiserFS: " in front of these messages?

In fact I think these messages should not be printed at all, there is no
useful information given to the user.

> >This is unclear to me. You mean to crash a system to get a copy of deleted 
> >file,
> >or to crash a system to delete a file? Both things sound very unlikely.
> Yes, no doubt, I really don't know what is usual in these cases. I
> should explain what happened to make me write this comment. I had
> recompiled one DRI module for X recently when my system decided to
> crash. After rebooot I had some truncates-to-complete. So far "normal"
> or at least "o.k.".
> But due to anti-aliasing configured in KDE it loaded everything but
> didn't show anything else than my desktops background color and the
> mouse arrow. It took me some time to figure out how to get things back
> into previous order. It finally seems like I just needed to reinstall
> the DRI component. But until now I don't know what files had
> disappeared/corrupted to get exactly and only these ones from my backup.
> You see? Yes, not usual, but...

No, actually I do not see, if some files have disappeared, reiserfsck
should tell you about fs errors, then (like lost files, or dir entries
pointing to nowhere).
Late deletes/truncates have nothing to do with disappeared files.

> >Hm? What do you mean by latest speedup-compound-patch? I know Chris does 
> >not
> >believe iicache should be good to use, because similar functionality (with
> >less overhead) can be achieved by pagecache.
> Pagecache? How can I adjust this? Where did I read this before...?

No code in reiserfs proper exists for that yet. But it may appear in the future.

Bye,
    Oleg

Re: BTW: 2.4.19-patches-to-come?

[Chris Mason]

On Wed, 2002-05-08 at 01:30, Oleg Drokin wrote:
 
> > I don't find this information very explicative. And I really don't know
> > enough about reiserfs code to interprete these lines. BTW, can we have a
> > "ReiserFS: " in front of these messages?
> 
> In fact I think these messages should not be printed at all, there is no
> useful information given to the user.

I like a summary line: completed X number of truncates and N number of
deletes.

-chris

Re: BTW: 2.4.19-patches-to-come?

[Oleg Drokin]

Hello!

On Wed, May 08, 2002 at 09:04:50AM -0400, Chris Mason wrote:
> > > I don't find this information very explicative. And I really don't know
> > > enough about reiserfs code to interprete these lines. BTW, can we have a
> > > "ReiserFS: " in front of these messages?
> > In fact I think these messages should not be printed at all, there is no
> > useful information given to the user.
> I like a summary line: completed X number of truncates and N number of
> deletes.

This one can stay, but I am not yet sure we need it anyway.
I think we should only print this stuff (keys of individual deleted objects
and total number of late deletions/truncates) if CONFIG_REISERFS_CHECK
was enabled, what do you think?

Bye,
    Oleg

Re: BTW: 2.4.19-patches-to-come?

[Chris Mason]

On Wed, 2002-05-08 at 09:08, Oleg Drokin wrote:
> Hello!
> 
> On Wed, May 08, 2002 at 09:04:50AM -0400, Chris Mason wrote:
> > > > I don't find this information very explicative. And I really don't know
> > > > enough about reiserfs code to interprete these lines. BTW, can we have a
> > > > "ReiserFS: " in front of these messages?
> > > In fact I think these messages should not be printed at all, there is no
> > > useful information given to the user.
> > I like a summary line: completed X number of truncates and N number of
> > deletes.
> 
> This one can stay, but I am not yet sure we need it anyway.
> I think we should only print this stuff (keys of individual deleted objects
> and total number of late deletions/truncates) if CONFIG_REISERFS_CHECK
> was enabled, what do you think?

I like the single line summary, it helps for things like Dirk Mueller's
problem report.  'every time my system <explodes into a ball of flame>,
it is preceded by messages about some number of completed truncates or
unlinks'.

It might point us in the wrong direction, but it is still good
information to have.

-chris

Re: BTW: 2.4.19-patches-to-come?

[Oleg Drokin]

Hello!

On Wed, May 08, 2002 at 09:16:15AM -0400, Chris Mason wrote:

> I like the single line summary, it helps for things like Dirk Mueller's
> problem report.  'every time my system <explodes into a ball of flame>,
> it is preceded by messages about some number of completed truncates or
> unlinks'.
> It might point us in the wrong direction, but it is still good
> information to have.

Ok. I will leave the summary line, then.
The specific key information will be only printed with CONFIG_REISERFS_CHECK
enabled.

Bye,
    Oleg

Re: BTW: 2.4.19-patches-to-come?

[Chris Mason]

On Tue, 2002-05-07 at 15:35, Manuel Krause wrote:

> 
> Mmh. I meant to restore the affected files from existing backups. When
> they are  removed by reiserfs on mount I know they are really corrupted
> during crash. It often looks like:
>   Removing [5523 5570 0x0 SD]..done
>   Removing [5523 5569 0x0 SD]..done
>   Removing [5523 5566 0x0 SD]..done
>   There were 3 uncompleted unlinks/truncates. Completed

Just to reiterate what Oleg said, these files were not corrupted during
the crash.  Right before you crashed, something on your box deleted each
of these files, but the delete did not have a chance to finish.  During
the next mount we finish the delete, which brings the FS back to a
consistent state.

-chris

Re: BTW: 2.4.19-patches-to-come?

[Manuel Krause]

On 05/08/2002 03:34 PM, Chris Mason wrote:

> On Tue, 2002-05-07 at 15:35, Manuel Krause wrote:
> 
> 
>>Mmh. I meant to restore the affected files from existing backups. When
>>they are  removed by reiserfs on mount I know they are really corrupted
>>during crash. It often looks like:
>>  Removing [5523 5570 0x0 SD]..done
>>  Removing [5523 5569 0x0 SD]..done
>>  Removing [5523 5566 0x0 SD]..done
>>  There were 3 uncompleted unlinks/truncates. Completed
>>
> 
> Just to reiterate what Oleg said, these files were not corrupted during
> the crash.  


I was very satisfied with this special clarification as I thought I've 
finally understood it.

O.k. and for the moment or so far I have not been able to prove this. 
Your statement may be or may be not. I had many VMware sessions crashing 
while / before e.g. "May 17 03:41:30 firehead kernel: /dev/vmmon: 
Vmx86_ReleaseVM: unlocked pages: 44944, unlocked dirty pages: 26020"

That may not matter for you as my kernel is too experimental as I've 
explained before.

> Right before you crashed, something on your box deleted each
> of these files, but the delete did not have a chance to finish.  During
> the next mount we finish the delete, which brings the FS back to a
> consistent state.
> 
> -chris
> 


As I had often only running KDE and VMware [?crashing] I did want to 
know what files were removed - the VMware ones and/or the KDE session 
temporary ones. That was all.

I don't know what of them two deletes files "just directly before" a 
crash. VMware is known (as of newest _official_ docs to unlink its used 
memory&Co. file(s???) in /tmp during startup... but what happens during 
a crash?) Dunno.

I was curious and I stay curious, as I don't see any program deleting 3 
files just before every crash...  (I don't have sizes, places and names...)

For my side it does not depend on the "summary line" that says merely 
nothing to me so far.

Best wishes,

Manuel

Re: BTW: 2.4.19-patches-to-come?

[Oleg Drokin]

Hello!

On Fri, May 17, 2002 at 03:49:06AM +0200, Manuel Krause wrote:

> I was curious and I stay curious, as I don't see any program deleting 3 
> files just before every crash...  (I don't have sizes, places and names...)

It is not necessarily happened to files direectly to a crash.
Any open file, that was deleted, cannot be deleted until it is closed.
e.g. if you'd do "sleep 1000000 </path/somefile ; rm /path/somefile",
/path/somefile won't be deleted until sleep finishes.
If system crash occured and there were still some open, but deleted files,
these files gets removed as part of recovery from crash process.
And it is not possible to find file's names/paths because corresponding
directory entries were already deleted.

BTW it is absolutely the same thing happens with ext2, once you see
e2fsck complains about "DTIME is zero", it deletes
not-yet-deleted-but-scheduled-for-deletion files.

Bye,
    Oleg

Re: BTW: 2.4.19-patches-to-come?

[Pierre Etchemaite]

Le Fri, 17 May 2002 08:56:11 +0400, "Oleg Drokin" <green@namesys.com> a écrit :

>  "sleep 1000000 </path/somefile ; rm /path/somefile"

I guess you meant:

$ sleep 1000000 </path/somefile & rm /path/somefile


BR,
Pierre.

Re: BTW: 2.4.19-patches-to-come?

[Oleg Drokin]

Hello!

On Fri, May 17, 2002 at 11:47:55AM +0200, Pierre Etchemaite wrote:
> >  "sleep 1000000 </path/somefile ; rm /path/somefile"
> I guess you meant:
> $ sleep 1000000 </path/somefile & rm /path/somefile

Yes, thanks for the correction.

Bye,
    Oleg

Re: BTW: 2.4.19-patches-to-come?

[Yury Yu. Rupasov]

Manuel Krause wrote:

> Hi!
>
> BTW, for 2.4.19-final it would be very nice to have...
>
> 1.) the deleted/truncated/completed-files-on-mount at least
>      printed in the kernel logs, at best with the real filename
>      -- as afterwards they are not retrievable --
>      That's a security reason -- whoever can trigger a crash
>      with various methods (I know the admin should take care
>      against this case... but on my home sytem I'd like to know
>      that info, too) but to get back the file from backups in
>      case... who knows it before a
>      crash... ? Am I missing something?
>
> 2.) a disk/drive/partition distinction in reiserfs related
>      messages -- Oleg, you promised it to get real and best
>      would be a real "patch" !
>
> 3.) a hint on how to turn on/off data-journaling for "some"
>      of our existing reiserfs partitions if it exists at all
>      for now and why it could be needed in some cases?!.
>
> 4.) a hint why there is iicache code in the latest
>      speedup-compound-patch (so that the latest iicache patch
>      would not apply)
>

The iicache patch is inside compound-speedup-2.patch already.
So, you can use just compound-speedup-2.

>
> Best regards for your stable ReiserFS, at all,
>
> even under "settings" with 2.4.19-pre7 +reiserfs.pending +latest
> reiserfs.compound-speedup +aa.vm-for-2.4.19-pre7 +akpm.read-latency-2
> +rml.preempt-kernel + rml.lock-break +some-more nice aa.patches...
> That's a valuably fast & interactive experience!
>
> Manuel

Thank you Manuel for testing,
Yura.

Re: BTW: 2.4.19-patches-to-come?

[Manuel Krause]

Hi!

On 05/07/2002 03:52 PM, Yury Yu. Rupasov wrote:

> Manuel Krause wrote:
> 
>>Hi!
>>
[...]
>>
>>4.) a hint why there is iicache code in the latest
>>     speedup-compound-patch (so that the latest iicache patch
>>     would not apply)
>>
> 
> The iicache patch is inside compound-speedup-2.patch already.
> So, you can use just compound-speedup-2.
> 
>>Best regards for your stable ReiserFS, at all,
>>
>>even under "settings" with 2.4.19-pre7 +reiserfs.pending +latest
>>reiserfs.compound-speedup +aa.vm-for-2.4.19-pre7 +akpm.read-latency-2
>>+rml.preempt-kernel + rml.lock-break +some-more nice aa.patches...
>>That's a valuably fast & interactive experience!
>>
>>Manuel
>>
> 
> Thank you Manuel for testing,
> Yura.
> 


O.k. I just assumed that (iicache=in) was true since reading and 
applying the patch and _then_ this "compound" is much more stable than 
the previous versions of iicache. I.e. it does not corrupt my Netscape6 
and KDE files-in-use any more. And it really does not show slowdowns in 
applications load times at all. Maybe Dieter could report the same.

I can't say if it is faster or slower as I revised my systems' chipset 
and bus settings (hdparm, lilo->kernel and powertweak) during the last 
weeks to have an overally more common and stable setup.

Thanks for providing a usable and  applyable patch on Namesys ftp, Yura,

Manuel